Wednesday, November 23, 2011

SDLC - Coding, Testing, Implementation, Maintenance Phases

Coding Phase

The LLD document contains all the details for a programmer to convert it into a working program. Designed in the right way, the job of the developer is to convert the pseudo code into a programming language in the specified platform. The developer will be given specific guidelines that tell how to code. This guideline includes the naming convention of procedures, variables, commenting methods etc. As per the guidelines, the developer codes and at the end of the coding, he/she compiles the program unit.

By compiling and correcting the errors, all syntax error and removed. Syntax errors are the easy ones to rectify. The logical errors in the programs are the difficult ones to identify and then rectify. By logical error, we mean, the program behaves in a way, that it is not expected to behave. The role of testers is to identify the logical errors at various stages.


*This section provides only a shorter version of the testing techniques.

Testing is the process of evaluating a system or application, to check whether the application meets all requirements of the client and to detect the errors.

Generally testing can be classified into static testing and dynamic testing.

Again Dynamic Testing is classified into two types: Structural Testing (or) white box , Functional Testing (or) Black Box testing.

Static Testing

Verification activities fall into the category of Static Testing. Static testing refers to testing something that’s not running. It is examining and reviewing it. i.e., to check whether the work done meets the standards of the organization. Reviews, Inspections and Walk-throughs are static testing methodologies.

Example: The specification is a document and not an executing program. When we read it to find out the issues, it is considered as static testing.

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.

Techniques used are determined by type of testing that must be conducted.

Functional ("black box") testing.

Structural (usually called "white box") testing.

Black box testing involves looking at the specifications and does not require examining the code of a program. Tests that examine the observable behavior of software as evidenced by its outputs without referencing to internal functions is black box testing. It is not based on any knowledge of internal design or code and tests are based on requirements and functionality. Nowadays there are automatic code generation tools and code re-use becomes more prevalent, analysis of source code itself becomes less important and functional tests become more important.

Black box testing is easy as it is based on system’s response for a given user’s input. If we know the business functionality of the product, we can do black box testing. On the other hand, white box testing requires programming knowledge to know the internals of the code. Also it is time consuming. So only a developer can become a white box tester.

Unit Testing

Soon after the program is corrected for syntax errors, the program has to be checked for logical errors, at the unit level. Programs may have simple user inputs or outputs thru screens or reports. The inputs must be validated for their format, data type, boundary conditions etc. Also, the elementary functionality of the program must be verified. In most of the cases, the programmers themselves will do this unit testing. Many inputs will be verified in this way and the program unit will be checked for the basic functionality in this phase.

If there are any problems while doing this testing, the programmers will debug the program and the bugs will be fixed and will be tested again for the bug fix. While doing the unit testing, that particular unit need not wait for another unit to be completed. It can be tested independently. Unit testing is also termed as component testing. For example, if we need to test a java class and method, even without any screen, the programmer can test the same. Thus any piece of code, that can be independently executed, can be independently tested as well. This is termed as unit testing.

Integration Testing

When all the individual program units are tested in the unit testing phase and all units are clear of any known bugs, the interfaces between those modules will be tested, to establish that they communicate to each other property via the specified APIs and thus they can be integrated into an application. The integration test may be performed by the independent testers or by the development team members.

System Testing

After all the interfaces are tested between multiple modules, the whole set of software is tested to establish that all modules work together correctly as an application or system or package. This is again performed by independent testes. The testers will have to do the system testing as though they are the end users of the application. Systems testing includes special testing methods like performance testing, interoperability testing, stability testing etc.

Acceptance Testing

After the software product is tested by the SDU in 3 different stages (unit, integration and system), the client will test it, in their place, in a near-real-time or simulated environment. This establishes that the software meets the requirements of the end user. This testing is carried out as though they are using the system in their real office, to mimic the real time scenarios.

Implementation Phase/Support

This Phase will provide users with the documentation and training required to use the system effectively. Data Conversion will only occur once, but user documentation will be required. Deployment of the product will be carried out, on the hardware that is going to be used in production (on live systems). Deployment itself requires careful planning. Once the product is deployed, initial data will be populated, user training will happen.

Release to Production and warranty Period

When the clients to the acceptance testing and finds no problems, then they will accept the software and now they have to start using the software in their real office. It may be a real bank for a banking application. During the acceptance testing also, there may be some bug fixed done to the software. Before the software is put into production (real time environment), the SDU must release the latest versions of the software, which has no known bugs to the client. This may be in a CD or tape or an Internet download. The clients will then install the latest software in their production system and will start using. This is called go-live process.

In the same way every product has a guarantee period software also has a warranty period. Normally it will be a 60-day or a 90-day warranty period for most kinds of software. Depending upon the complexity and size of the software the warranty period may be extended or shortened. During this warranty period, in case of any problems, the SDU has the responsibility to rectify the problem, at no charges. Again, it depends upon the contract, whether to charge for the fix or not and may vary from industry to industry.

Maintenance Phase

After the warranty period, the software enters the maintenance phase. During the maintenance phase, 3 things happen to the software. They are :

Bug fixing



During the maintenance phase, because of some untested scenarios, the software may give errors or logical problems. This has to be fixed. This is same as any other bug fixing. This is similar to any repair works done to a vehicle, by its owner.

In the software field, the software versions are constantly changing and the applications may have to keep themselves upgraded to the newer versions of the software. For example, the anti-virus software must be constantly upgraded to address new viruses, which come very day. If the operating system version charges, it may necessitate to introduce some changes in the programs. So, this kind of upgrade works to the existing software applications, because of operating system or environmental changes or hardware changes may have to be incorporated.

Any software is not all complete and there are enough rooms to add new features to an existing software. For example, today the railways reservation system may not be in the internet; but tomorrow there may be a need to go in the internet way. So, new modules are to be added to the existing system to address this. This is enhancement.

After some time, the software may become obsolete and will reach a point that it cannot be used. At that time, it will be replaced by another software which is superior to that. This is the end of the software. The software will reach its end, when the maintenance cost of the software becomes more than the new software available. Software can become obsolete when the company does not upgrade it to work on new environments such as databases or operating systems. When the software becomes incompatible with the environment, users will move on to another software, dumping the existing one.

For recorded training content, please visit

Monday, November 14, 2011

SDLC - First 3 Critical Phases

We have been getting very good feedback from audience of this blog. Even experienced readers convey that they refer this to their team members, to learn complex things in simpler way. Thanks to all.

Software Development Life Cycle

The Various activities which are carried out when developing a software are commonly termed as a software Development Life Cycle (SDLC). The software development life cycle begins with the identification of a need for software and ends with the formal testing of the developed software against the requirements.

A software project is made up of a series of phases; most software projects comprise the following phases:

  • Inception Phases
  • Requirement Analysis Phase
  • Design Phase
  • Coding Phase
  • Testing Phase
  • Implementation Phase
  • Maintenance Phase

Inception phase

Request for proposal

The first initiative that happens for the development of a software product, is the need for someone to automate or computerize their system, e.g. a bank willing to automate its day to day activities. When the need is felt by the concerned unit, they will give a formal advertisement in the media that they need a software product for their automation. This may be in newspapers or on internet or private letters known software development people. This process is called Request for Proposal (RFP).

In the real world it is called as tender also, in many situations. When there is a need, the state highways department may want to lay road for 100 miles, at a particular stretch. In that case they will give a tender notice in newspapers inviting people to give their proposals. RFP is a similar one. The tender may contain minimal information about the need; and it may not be sufficient for the bidders. In those cases, the sales department of a software development company will approach people to identify the needs. The sales department will keep its eyes and ears open to see any open tenders, that can fit into their business.


When the software development company finds that there is an RFP, they will prepare a formal proposal and sent it to the concerned unit that needs the software product. The proposal will contain: Time frame in which the project will be executed, Milestones of the projects activities and the respective start and finish dates, Cost involved in the project, Number of people likely to work in the project and their skill sets, Hardware and software requirements for the project, an overall architecture of the system, the technology that will be used to develop the software, Credentials of the software development company including annual turnover, manpower, past experience in executing similar kinds of projects etc. The cost and time will be estimated by project manager or any appropriate senior person, who possesses this kind of estimation experience. The success of the project greatly relies on the accuracy of these estimates.

These details will be provided in a single document and will be sent to the concerned unit. This is called Proposal. In colloquial terms, this is called a quotation. Many Software Development Units (SDUs) will send their formal proposal to the unit, which needs the software. Obviously each proposal will differ in terms of cost, time, people etc


When the company receives multiple proposals from various SDUs, they have to identify a suitable SDU, which can provide the required software product with minimal cost, in a minimal time frame, through an optimal technology. To identify a particular SDU among multiple SDUs, the company, which needs the software, may call all of them or a few of them based on the credentials and other parameters stated above for further clarifications. During this process, SDUs will be asked for a lot of technical and functional clarifications and also to reduce the cost and to shorten the time frame. This happens invariably in all projects and this process is called negotiation. After one or more rounds of such talks, the company may identify a suitable SDU as the unit that is going to develop the software. In this process, both the company that needs the software and the identified SDU are in agreement of the terms, in terms of cost, time, technology etc.

Usually the senior management team and sales team are involved in negotiation process.

Letter Of Intent (LOI)

Once an SDU is identified, they will be given a formal letter by the company, which needs the software, stating that they are willing to proceed further in the development process. This is a pre-cursor to signing a contract. This is only an informal assurance that the deal is closed. Also, LOI alone cannot stand as the final document to start work.


Feasibility Study

Once the Letter Of Intent is given to the SDU, the SDU may send some people to the client’s place to do a preliminary research to know the feasibility of the automation. This may be for a shorter period. This is called Feasibility Study. In this process, the SDU will come to know about the complexities and the difficulties in implementing a computerized solution.

This study may occur even before the proposal stage, in some cases. But there is a disadvantage for the client, i.e. inviting multiple SDUs to do the feasibility study. If this happens after the LOI is issued, then it will be one SDU, that does this work in a focused manner and this will help the client in passing on the project information in a quick and efficient manner.


After the negotiation is complete, LOI is issued and the feasibility study is furnished, there will be (may be) another round of re-estimation of the cost and time. But this may not vary in many cases from the original estimates and many clients do not want any further increase in the cost or time. Then the SDU and the client will formally sign a contract, which clearly specifies the timeframe within which the project must finish, the cost involved, the technology to be used, the hardware and software setup etc. This is the commitment document that serves as the basis, throughout the project. The contract will include many clauses regarding the legalities and any other penalty charges in case the SDU is not able to keep up its promise.

There are projects, in which the time is not fixed, but the work is measured in terms of person-days and the cost will be paid on an hourly or daily basis per person. Contract usually contains many legal phrases that describe about payment terms, warranty period, dispute handling and jurisdiction, any other specific terms as agreed in negotiation, protecting the intellectual property rights etc.

Requirement Analysis phase

After the contract is signed off between the SDU and the clients, this phase is the main focus of the project managers and stakeholders. Meetings with managers, stakeholders and the users are held in order to determine the requirements.

User Requirement Specification (URS)

The SDU must now know what the client wants in the software project. To ease the process, many clients (alternate terms for clients are customers or users), prepare formal documents, which describe their need. This document will describe in detail about what is expected out of the software product, from the users perspective. This is called User Requirements Specification. This will use the same terms and nomenclature that the customer uses in the day to day business.

This is the base document for the functionality of the product. This will be prepared and reviewed by the user community, mainly by experienced users. As an example, the URS of Railways reservation system will talk about how the reservation, cancellation etc. are carried out in an actual reservation counter. The very idea is that, these are the activities that are going to the computerized and if these are properly documented, then it will be easy to proceed in the actual product development. In some countries, a few clients write this document in their native language and not necessarily in English.

Software Requirements Specification (SRS)

After the URS is defined, a team of business analysts, who are having a very good domain or functional expertise, will go to the clients place and get to know the activities that are to be automated. This includes thoroughly understanding the URS, item by item. The URS may not be in an understandable language and format, for the developers and testers. So SRS is derived based on URS, to provide clarity to the development team. If the SDU does not know what is to be computerized, it cannot develop software that satisfies the customers. So, understanding the requirements is very essential in software in software development process. Most of the times, the business analysts, together with expert users, will frame a single document, which will serve as both URS and SRS. This way, there will be only one document which will serve as a functional commitment document between the customers and the SDU.

Requirements Collection

The role of a business analyst is very vital to this process. Before we start talking to clients on project features we must know the domain well. The SME (subject matter expert) meets various people who are in charge of the day to day business activities in customer’s core business. For example, if we develop a software for an insurance agent, we must know what he/she does with customer, we must know what detail he/she collects, how they fill up forms, how they arrive at premium amount, who approves it etc. if this can be clearly documented in plain English, the same can be used for development.

The SME must collect all fillable forms, receipts, reference numbers, approval papers, etc. Also the pain areas of customer must be documented so that the same can be computerized.

The SME must talk the same language, jargons, code words, acronyms with the customer, This will create trust with users and they will exchange more information to SME. The SME must make no assumptions. If there are any open or doubtful issues, that must also be documented along with the specs as annexure. Any sample forms must be scanned and attached to the specs. Specs can contain flowcharts as well. See the example flow for a car service centre.

Before going and meeting the client, the SME must do a lot of home work and prepare a clear list of questions. The time one spends with client is very precious and we must not waste client’s time. Simple questions like a checklist will answer complex issues. Eg.

1. How many levels of approval is required for a purchase order?

2. Do you apply service tax for your services or are you exempted?

Once the SME drafts the requirements as described by the customer and end users, the specs must undergo an internal review. The project manager must review the specs. Then the same must be sent to the client for review. The review will clearly bring out the understanding level by the SME on what the customer wants. There are chances that the SME missing some of the points told by customer, or the SME understood it in a different way or the SME added something that the customer did not want/tell. Hence customer must review the specs very carefully. Once customer raises questions on the specs, SME must correct those areas and resend for review. This may take a few back and forth emails, a few telephonic calls etc. Finally when the customer says, “Yes, this what I want in the software”, ask him to send an approval email or to sign off and printed version of specs.

Design Phase

High Level Design (HLD)

Based on the SRS, now the software systems analysts will take over to convert the requirements into a usable product. In order to achieve this, the systems analysts must design the application, which will help the programmers in coding. In the design process, the product is to be broken down in independent modules and then taking each module at a time and then further breaking them to arrive at micro levels.

There are 2 different approaches followed in designing,

1) top-down approach and

2) bottom-up approach.

In top-down approach, the product is broken continuously into smaller levels till it cannot be broken to further levels. In bottom-up approach, the smaller levels and designed first and the used as building blocks to go to next higher level till we reach the complete product level.

The HLD document will contain the following items at a macro level. In HLD, the systems analyst describes what is to be done in the product. It will not go in depth into each component of the product.

List of modules and a brief description of each module.

Brief functionality of each module.

Interface relationships among modules

Dependencies between modules (if exists, B exists etc.)

Data elements that are used by customer

Overall architecture diagrams along with technology details.

This document is one step ahead SRS, to convert the requirement into a product. This is mostly a single document, for small to medium size projects. But if the application is large, then there may be multiple documents, which form the whole HLD. Each document may describe a separate module.

Low Level Design (LLD)

HLD contains details at a macro level and so it cannot be given to programmers as a document for coding. So, the systems analysts prepares micro level design document, called Low Level Design. This document describes each and every module in an elaborate manner, so that the programmer can directly code the program based on this. There will be at least one document for each module and there may be multiple LLDs for a module, depending upon the complexity of the module.

The LLD document will contain the following sections.

Detailed functional logic of the module, in pseudo code.

Database tables, with all elements, including their type and size

All interface details with complete API references ( requests and responses)

All dependency issues between modules

Error message Listings

Complete UI design of how each screen looks like

The HLD and LLD phases put together is called Design phase. Design must be done only by experienced people. Design itself has its own guidelines to be followed; most of the times, people use design patterns to find out what will be the best design for a product. Already there are many experts in the world, who have designed big products; they had published the way they designed. Instead of reinventing the wheel, we can try to reuse those already proven designs, if they fit our software.

For free learning material, visit us at

Thursday, November 10, 2011

License To Crack - Introduction to Testing


This book will provide a brief introduction and overview of software testing, discuss about entire process carried out in the IT industry, and introduce the concept of blended testing. It aims at providing a practical know-how to the reader.

Software Testing, that define Software Quality, is of major importance to all the software companies in today’s highly competitive filed. Every software application is a jig-saw puzzle of many tiny programs, assembled together. Yes, a developer can develop products and check the functionalities of the product, but he/she can never certify the quality and stability of the product; especially, after the integration of his modules with those of his co-workers.

A product can be made better (or at its best) only after it goes through a proper process of development, testing and bug fixing. Not only should it go through this process, but there should also be a good and healthy relation between the developers and the testers to attain this objective.

Software testing is both a discipline and a process. Though software testing is part of the software development process, it should not be considered part of software development. It is a separate discipline from software development. Software development is the process of coding functionality to meet defined end-user needs. Software testing is a continuous process of both validating functionality, and, even more important, attempting to break the software.

Software companies face serious challenges in testing their products, and these challenges are growing bigger as software grows more complex. All developers know the frustration of having software bugs reported by users. The first and most important thing to be done is to recognize the complex nature of testing and take it seriously. This part of software testing gives you a basic idea of software testing, why it is required, what steps to follow, and how it is different etc.

Software testing is often used in association with the terms verification and validation. Verification is the checking or testing of items, including software, for conformance and consistency with an associated specification.

Software testing is just one kind of verification which also uses techniques such as reviews, analysis, inspections, and walkthroughs. Validation is the process of checking that what has been specified is what the user actually wanted. Validation ensures if we are doing the right job and verification ensures if we are doing the job right.

Debugging is different from software testing and should not be confused. Debugging is the process of analyzing and locating bugs when software fail to behave as expected. Debugging is therefore an activity which supports testing, but cannot replace testing.

Static analysis and dynamic analysis are other activities which are often associated with software testing. Static analysis investigates the source code and dynamic analysis looks at the behavior of the software while executing.

Industry Difference

There are some significant differences between software industry and other industries. If we take pharmaceutical industry there are many chemical manufacturers; there are many different production plants that mix these chemicals and make a specific drug. These drugs need to be packaged, transported to different cities and to retail pharmacies. Assuming an incident in which some drugs caused bad side effects in a particular city, the drug company need to ensure that it is addressed within hours, submit legal documents on quality, replace drugs and battle any lawsuits!

Assuming a manufacturing company that provides ball bearing to a car company and the dimension of the bearings are smaller by 0.1mm in dimension! Same issue to replace, transport, etc. Moreover we need more raw materials to rebuild some more parts; we need more time, transportation. What are we going to do with the facility drugs or bearings? It requires more expenses!

In software, there is no transportation cost, just redo and email/ftp the new software. There is no wastage of raw material. There is no waste disposal. Any other industry, the defect or mistakes are visible very obviously, quickly, if a food item is stale, we can feel immediately, if a car driver makes mistake while driving, it will be visible clearly, but in software, we cannot fine the defects easily, once the code is compiled and built all mistakes are buried in binaries.

Most of the times one portion of the software will work; another area will fail. We cannot see through the software fully, easily. No one is directly physically hurt if a software fails. If an artificial respirator fails, due to software defect the first doubt by instinct goes towards the equipment and not to the software that controls it. So, a mistake made in software is not easily detectible. If it is not easily detectible, it gives more room to make mistakes!

Testing requires a mindset to find issues. The first and foremost quality for that is “Attention to details”. Let us have a small exercise. Just mentally list one all the parts of a two wheeler or four wheeler vehicle. Count how many parts you are able to do so. Your time starts now.

Hope you are done. Le me ask a simple question. Did you list the fuel tank cover, fuel tank cover open knob, seat cover, engine temperature indicator, battery, foot rest…. Do you agree that you missed at least 2 parts out of the above list? So many years you see and use, yet you miss. That is what to be found out in testing. What a developer misses, that should be caught by a tester.

Did you observe one more thing where you listed out the parts? First minute you would have listed fast, next minute you slow down, 3rd minute onwards you feel like not getting any more parts. Human mind needs constant push. We need to push it saying “There is some more left, unnoticed”. So did it! A test must never give up.

Cost of Poor Quality

When Companies produced defective products and the products reached customers that are where the problem starts. If customer finds out the problem, the first thing that goes off is the trust of the customer on the product and the company. Rebuilding trust is a bigger problem than fixing the problem itself.

One leading mobile phone company called 2 million phones back from users, due to a faulty battery. A leading tire company called 60000 tires from car manufacturers since they found out that the tire catches fire at 60 mph on a curvy Road! A leading toy company went bankrupt, since a customer found out that paint used on the toys had poisonous lead content. A fortune 100 company incurred a cost of 0.75 billion dollars to replace its faulty gaming console component.

So prevention is better than cure.

I never fail attitude

I wrote my maths exam in 12th grade. I thought I would get 198 out of 200. But I got 192 out of 200. Am I wrong or my teacher who corrected the paper is wrong? We inherently make mistakes that are not visible to us. If another person sees it, the mistake is evident and obvious.

The same is triggered and amplified by an ego. If someone challenges a problem in our work our ego forces us to say “I am right”. This is instinct. To overcome this is a tough task. Every programmer or a software developer feels the same way. “My code never fails” on the same line, every tester feels “Your code always fails”. Also people feel hurt when the mistakes are pointed out. Some people are afraid to point the mistakes out on others. But we can learn better and faster from our mistakes.

Basic Questions on Testing

What is Software Testing

Software development is a process in which a software product or project is developed to fulfill the needs of a customer and deliver them with specified cost and time period, Who would want to make products of no standards or stability in today’s IT world? Well, if there are any, then they are the ones who do not consider Software Testing as a must. They also do not consider the quality of the product. It is a process of evaluating a system manual or automatic means and verifies that it satisfies specified requirements or identifies differences between expected and actual results.

Why to test

The very basic question that arises in everyone’s mind about testing is Why to test? .Talking in terms of real life situations, we Check any vegetables before we buy, we Check the television before we buy and we Check the car before we buy and so on. So, we check or inspect the article/ object, before us using that. This applies to software also and software is no exception to this.

To better understand the important of testing, let us take a typical banking application, which uses software. If the application is going to wrongly post the transaction, and the balance is not shown correctly, the bank will start losing its business. In a nuclear reactor, the control mechanism of nuclear explosion is taken care by a sophisticated software; and if that does not work properly, the rector may act as a super, it has the same ability to perform 10000 wrong operations in one second, if not tested properly.

So, testing becomes absolutely essential to make sure the software works properly and does the work that it is meant to perform. A product can be made better (or at its best) only after it goes through a proper process of development, testing and bug fixing. Not only should it go through this process, but there should also be a good and healthy relation between the developers and the testers to attain this objective.

What to test

Any working product which forms part of the software application has to be tested. This includes any programs and the associated data. The program may be an exe file or a servlet or an active server page etc. The data also must be tested for accuracy. Date includes the database information an any stored procedures or triggers that act on the data.

Among the programs and data, the programs need more attention and must be tested rigorously. If the programs are tested right, there is a higher probability that the data will also be correct, but not necessarily.

How often to test

Since the programs and date are tested, testing has to be performed, wherever they change. When a program (source code) is modified or newly developed, it has to be tested. The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. In short it can be termed as “Creatively Destroying the Product”.

Also, whenever the future and volume of data changes, the application has to be tested. As an analogy, when we buy a new television, we test it before taking it home. At the same time, in case of any repair work, we re-check or re-test the television unit, before we take it. This is applicable to software also.

Who tests

When a programmer initially codes a program, he/she himself/herself test it. This is similar to a student who writes an exam, checking the answers by self. This is to make sure that the price developed by the programmer meets the expectations of the programmer. This is first round of test, that the software piece undergoes. After the programmer makes sure that the software piece works fine, their is a separate team that ensures that the software product works as per the requirements. It is typically the testing team that does this round of testing. This way, the software is observed by different pairs of eyes. This is similar to a teacher evaluating the answer papers of the student, for correctness.

Finally the software is tested by the customer/client/end-sure. Because the software is going to be used ultimately by the client, in his/her place. This is similar to a person, buying a car, is actually doing a test drive of the car, before buying the car.

Product Company vs. Project Company

A Project company survives on the number of contacts that the company has and the number of Projects that the company gets from other forms. Whereas a Product based company’s existence depends entirely on how its product does in the market.

A Project Company will have the specifications made from the customer as to how the Application should be. Since a Project company will be doing the same kind of Project for some other Companies, they get to be better and know what the issues are and can handle them.

A Product company needs to develop it’s own specification and make sure that they are generic. Also it has to be made sure that the Application is compatible with other Applications. In a Product company, the application created will always be new in some way or the other, causing the application to be more vulnerable in terms of bugs. When upgrades are made for the different functionalities, care has to be taken that it will not cause any other module to not function. When any functionality is being implemented, have to make sure that they are introduced in such a way that it will not cause problems in the future for up gradation and for implementation of any other new functions.

Challenges in testing

To report a mistake on someone else’s work, is not that easy. People often feel hesitant to do that criticism. By not telling the mistakes, they do more damage to the work and the person who did it. It depends wholly on how you convey the issue rather than what you convey. There are people, by nature, who blame and who do not blame. When it comes to testing, we need to get rid of that subtle human mind block and call a spade a spade. Getting this mind set will be the first challenge.

The issues in software often surface as we start using the software. When a problem is identified when the customer uses, that puts more pressure on the people who tested the software and certified. This leads to project post-mortems late in the development cycle and it may even cause client dissatisfaction. So drawing the boundary of testing is another challenge.

Most of the fresh people who form the majority of the IT work force, do need action on the software. When a person codes, he/she sees the software running in front of the eyes; whereas in testing, you need to think a lot and document a lot. Many people are not used to this in their academia. This causes a discomfort in people and this takes time for people to gain the expertise of test planning.

The management teams always face time delays and pressure on testing. When sufficient time is not provided, the testing may not complete. The management will think of just completing the project schedule but may miss the project quality.

There is a great amount of difference between the service companies do testing and the product companies do testing. When people move from one type to the other, it takes time to adjust to the processes adhered by the companies. Process orientation is a human challenge every company faces.

In most of the countries, getting seasoned testers is a major challenge. Get the guy who cracks every software – very easy to say, but where are those guys? It takes a longer training period to create such a good code cracker. The reason is that the testing is more of a mind process and it involves a better understanding of the software than the creator of the software.

Tune your mind

Hope you had used the remote control to operate the television and the video player. Imagine that I sell a remote control unit to you and you want to ensure that it works perfect, before you pay me money. How will you test it?

Wait, do not start actually testing it. First write it down on a paper, a set of things that you will test on the remote control. How long do you plan to test the same? What else you need to test the remote control? Spend about 30 minutes and see how many tests you had written down.

You can observe a few things like this. First 10 minutes, you could have got a lot of ideas flowing in your mind and you would have written more tests. Then you could see some slow down in that process. During the last 5 minutes, you might have written only a few. Isn’t it?

You could see jump of thoughts when you read what you had written. Fifteenth point and sixteenth point, are they related to each other or different from each other totally? For example, 8th point would be to test the battery life and 9th point would be the forward option in video player panel. The tests will not be coherent when you read one after the other.

After 2 hours, you read what you had written. Do you understand what you had written? Or are you getting a doubt of why we had written this? Now, ask another person to read what you had written. Does that person understand what you had written or he/she has difficulties in understanding what you had written?

Now do this exercise, and spend 30 minutes for writing the tests for a lift (elevator), mobile phone, and microwave oven. You will see a change in you. What is that? Clarity in thought.

For recorded training sessions, please visit