Testing J2ME Applications

Hi Guys,
              Its been a long time since wrote an article since  I was busy on the personal front. Today I will be discussing about a topic that is something I am very passionate about  and that is none other than J2ME Testing. 

What is J2ME ?
J2ME(Java 2 Micro Edition) is a  framework from Java that is used for writing programs and applications for  mobile devices such as mobile phones, PDAs, smart phones,tablets,set top boxes etc.  In J2ME  an application specification is given by two terms. They are :-

1. MIDP(Midlet Information Device Profile)
2. CLDC(Connected Limited Device Configuration)\CDC(Connected Device Configuration)

  The CLDC is a Library that provides API for devices with minimum resources such as mobile phones and PDAs . It also  provides networking capabilities to the application and upward compatability with other Java Libraries like J2EE and J2SE.

The CDC is a Library that provides API fro devices such as tablets, set top boxes, Television etc.It also  provides networking capabilities to the application and upward compatability with other Java Libraries like J2EE and J2SE.

MIDP is a set of Java API. Both MIDP & CLDC work together to provide complete application runtime environment for mobile phones

As a matter of information I would like to tell you all that J2ME application runs on KVM(Kilo byte Virtual Machine) unlike other Java Applications  that run on JVM(Java Virtual Machine) . We use KVM instead of JVM as JVM cannot be deployed on these devices due to resources constratints.

All applications that are developed using J2ME APIs are called MIDlet. The MIDlet runs on Application Management Software(AMS) that is already installed in MIDP devices. One J2ME software can have multiple MIDlets bundled in it.

The MIDlet has a life cycle.It has 3 stages

1. Active State: When the currently invoked MIDlet is running
2. Paused State: When the currently invoked MIDlet is paused due to interruptions such as phone call, SMS etc
3. Destroyed State: When currently invoked MIDLet is exited\destroyed.

     The diagram given below will give a clear picture of the MIDLet lifecycle.

MIDlet Life Cycle

Ok Dude now I know what is J2ME.What are the testing aspects here ?
Though J2ME seems simple. There are numerous aspects of testing to these applications. They are as follows:-

• Functionality Testing
• State Based Testing
• UI Testing
• Exception handling Testing
• Persistant Storage\RMS Testing
• Generic Connectivity Framework(Such as SMS, GPRS,Bluetooth) Testing
• Device Compatability Testing
• OTA(Over The Air) Deployment Testing
• Performance Testing

I will now be discussing each of these in detail.

Functionality Testing
Like any other testing the aim of the testing is to find out whether the application is doing what it is supposed to do and not  doing what it is not supposed to do. This includes input validation, validating application workflows, login validations to view  the application etc.This can be tested both on device and an emulator. If any exception is thrown which makes the application to quit must be reported as a bug in this phase

State Based Testing
 This Testing is to ensure that MIDlet lifecycle is carried out smothly while the MIDlet is running. In certain cases A MIDlet cannot be exited when doing certain critical opertaions such as fund tranfer from one bank account to another. The AMS should not allow the MIDlet to exit, Such testing can be done in this phase. In such cases the IllegalStateException  is thrown and this does not allow the user to exit. Also in cases of any interruptions such as phone call or sms, the application must be observed as how the applications  goes to paused state and resumes once when the high priority process is over.

UI Testing
This testing mainly focuses on whether the UI is user friendly or not, The UI navigation of the application and whether proper GUI objects are placed for certain operations. Eg: If an application is doing a Bluetooth Search a Gauge has to be placed on the screen with appropriate message. Instead if a blank screen or the existing GUI is displayed then it is considered as a bug as it gives a notion that the application is hanging. Also any exception thrown from UI must be handled accordingly. If any exception(from UI perspective) is not handled then bugs must be raised for the same.

Exception Handling Testing
This testing maily comes in White box testing particularly in Unit Testing Phase of V & V-V model. For every exception handled in the code the tester must try to create a situation such that the exception is handled by the application and the appliucation does not crash. This enables to understand how the application behaves in the environment. Also any unhandled exceptions can be found by this testing. This has to be done for all parts of the code written for each and every MIDlet

Persistent Storage\RMS Testing
This Testing comes part of White box testing. RMS is a storage facility in J2ME applications for storing data. It is somewhat similar to file handling. All information are stored in the form of byte array in the RMS. Data entered here must be  stored in Type-Length format in the byte array for each record. An example is given below

TL Format in RMS

The testing scope here would predominantly be whether the records are being successfully stored and retrieved from the RMS without any exception thrown. Whether all exceptions are being handled or not. Whether searching for a record is efficient etc. Some exceptions handled here are RecordStoreNotOpen Exception,RecordStoreFullException,RecordStoreException:raised when a genral exception happens in record store,SecurityException.

Generic Connectivity Framework  Based Testing
Generic Connectivity Framework(GCF) is Framework of J2ME that uses Network Connectivity such as GPRS, Socket Connection, SMS,Bluetooth,Infra Red etc. It is this framework that gives the potential for mobile devices to compute despite having  minimum resources. In this section I will be discussing about SMS,GPRS and Bluetooth based testing below:-

SMS Based Testing
In SMS based applications there are two types of SMS.
1. Text SMS
2. Binary SMS
In Binary SMS the payload data is converted to bytearray format while the message is sent through the channel.However this does not mean that the SMS is secured.
Also SMS can be sent to specific ports in mobile devices and servers. In case of specific ports the SMS will be delivered only to the application and not to SMS inbox of the mobile devices.

So the basic functionality that a tester can test here are
1. Whether the Binary SMS is converted and the SMS is the same as it is at the Sender's side
2. SMS are being sent and received by the client and server
3. For port specific operations a tester needs to check whether the client is able to receive the SMS in the application and not in the SMS INBOX
4. For port specific operations whether the server is receiving the SMS in the specific port
5. Whether the client is able to receive the SMS at the specified port
6.Whether the mbile application is able to send the SMS in the specified port
7. If connection is disconnected during critical operations whether exceptions are handled or not. Whether the operations in server is rolled back or not.

GPRS Based Testing
In GPRS based operations the mobile device connects to a web\application server. The server process the request and then sends the response to the mobile device. 

Here testers are required to test the following:-
1. Whether the mobile device is able to connect to the server at the given port smoothly without throwing any exception
2. Whether the mobile device is able to send GET and POST request to the server
3.Whether the Server is able to receive the request
4.Whether the mobile deivce is able to receive the response from the server
5.Whether the mobile device is able to understand the response from the server

Tester should also ensure whether the IOException has been handled or not as a lot of information exchange tends to happen and the control of the system tends to get lost easily. So the application must be robust and reliable at the same time even when control from the user is lost.

Bluetooth Based Testing 
In J2ME communication through Bluetooth can be taken place using L2CAP layer and the RFCOMM layer.
Devices should not be able to detect more than 30 devices within its bluetooth range.Information sent through Bluetooth are sent in bytearray format. 

The following that are to be tested here are:-
1. Whether the mobile application is able to detect devices in the given region
2. If the device is able to detect devices is it able to detect all devices if number of devices within the given region is less than 30
3.If there are more than 30 devices, is it able to detect exactly 30 devices 
4.Whether the mobile application can connect to the device in the specified layer
5.Whether the two mobile device running the same mobile applications are able to send and receive messages
6. If the two mobile devices are able to send and receive messages then both mobile devices should be able to produce the same information as sent by the sender
7. Whether the mobile devices are maintaing connection within the specified bluetooth range
8. If the Bluetooth connection disconnects abruptly during critical operations how the application responds.
9.Whether BluetoothException is handled or not

Device Compatability Testing
Although most mobile phones have the same specification of MIDP and CLDC a device compatability testing has to be done since each mobile phoone's configuration is different. This testing has to be done by deploying the application in each and every mobile phone and checking whether the functionality is working fine, display is proper, GCF such as bluetooth is compatable with other mobile devices or not etc.

Generally when mobile application is developed several versions are created that are targetted for certain mobile phone.eg: we have angry birds for nokia s6 phones, iphonone,blackberry etc.

OTA(Over The Air) Deployment Testing
J2ME applications can be directly downloaded to the mobile phone using GPRS\EDGE\W-LAN\3G connectivity. This is called OTA Deployment. The deployment takes place by typing  the link address of the JAR or JAD file of the application that resides in the server on the mobile phone. The application  genrally gets donwloaded into the phone memory directly.

What needs to be ensured here is that the JAR file is built correctly with the right MIDP and CLDC configurations. If JAD file is being deployed in the server the specification of the JAD file needs to be verified.

Performance Testing
In mobile applications what is crucial is the space utilized by the mobile applications since the mobile devices has a very low physical memory.Also thread utilization also has to be minimal although it is very difficult to do without using of threads. The emulators provided by the IDE(NetBeans and Eclipse) provides features of checking these parameters while testing the application. These parameters in turn affect the quality of the application

I hope I was able to throw some light on J2ME testing.

Till then Cheers From,
Sai :)

Conducting User Acceptance Testing-Best Practises

Conducting User Acceptance Tesing (UAT)  is something that is challenging, interesting and fun, although the client with  whom I work with is not easy to handle. UATs are conducted in two ways in the industry. One way is having a F2F meeting with the client and demonstrating the functionalities in front of him. The second way is by conducting a live meeting i.e. The testers who work offshore, share their desktops with the client and demonnstrate the functionlitites on their desktop, the explanation is given on the phone.There are a few things that one needs to do before and during the UAT in order to ensure that the UAT is successful for both the methods.

Before the UAT:-

1. While completing the System and Integration testing always conduct a  complete ad hoc and exploratory testing. This ensures less defect slippage and prevents embaressment in front of the client .
2. After the completion of System and Integration Testing always obtain a sign off from the client on the scope and objectives of the module that will be tested., the test cases, different scenarios etc. This is to ensure that the client is aware as what is going to be demonstrated to them. If corrections are  made to  test cases and scenarios, they can be modified at this point, but a change in scope,objective and requirement at this junction should always be taken as a new module as the change in scope,objective and requirement will always  increase cost, decrease quality of product delivered  and increases dissatisfaction of the client. In case if client does so it is to be explained to him/her in a polite manner. Never start the UAT without the client Sign Off
3.   When the module is released in the UAT enviornment always conduct smoke testing and simple end to end testing of the entire functionality. This helps in solving enviornment issues, certain configurational issues such as user configuration issues, deployment issues, ensures that the worflow is running without any visible bugs(although by this point the module should be almost bug free !!!!). In a way this also prevents embaressment in front of the client. 
   I would like to share my experience in a lack of end to end testing before a UAT. There was functionality of creating a Service Request  which involved three required  fields that were chosen from a drop down box they were Type, Area and Sub Area. However this was part of an old module that I had tested around 3 months back. When a new module was to be tested by me this old module was dependant by the new module. During the end to end testing I did not test whether the system was not accepting a Service Request without either Area\Sub Area. During the UAT when I was creating a service request I accidentally pressed a short cut key that saved the service request without Area and Sub Area . This was a bit embarassing in front of the client. Hence what I am trying to say here is always ensure that end to end testing is properly done
4. The next step is preparing the platform for conducting the UAT.If the UAT is conducted through live meeting always test the live meeting session(Sharing desktop from the system from which demonstration will be done) before sending the invite. Also check if the telephone is working properly especially the speaker phone. In case of F2F meeting and demonstration always book a room with  a projector and ensure that the projector and the system are compatiable 
5. Be in time for the UAT. Always ensure that you are ready 30 minutes before the UAT. 
6. Get all issues and problems clarified with the leads and the Business Analsyts so that they can be handled by the testers alone. But always ensure that the Test Leads and the Business Analyst is always there when the UAT is being conducted 
7. Ensure adequate test data is setup for all the test cases, so that the tester does not have to create test data at the time of demonstration 
 

During the UAT 

1. When the UAT begins especially in case of live meeting always clarify and ask the client whether is he able to view the screen, notice the movement of the screen, whether there is any lag in the movement of the cursor and whether the client is able to hear the tester without any distrubance . If not then then take steps accordingly 
2. While executing each test case  first read out the test case objective, by showing the test case to the client either through live meeting or through the projector and then execute the same. While executing explanation would have to be given so that the client can understand the work flow of the module 
3. Whenever client  has any issues always answer him\her politely and execute the steps again if he\she has any doubts or clarifications 
4. Never argue with the clients  beacuse clients are always right 
5. If clients tend to move out of scope and force the testers to move out of scope always politely refuse the same to them. If they do not agree always take help from your Test Leads and Project Manager  to support you 
6. In case of any disagreement politely explain it to the client. Do use proofs such as letters sent by the client on sign off on requirements etc to support your facts. 
7. Whenever client raises observations and triage results always note them down on notepad\sticky notes software on the system so that it is transaprent to the client in case of live meetings 
8. If bugs are raised by the client and are valid accept them with a lot of courage. If the bugs are not valid, convince them and take them as observations\triage results
9. After ending the UAT show to the client which all test cases have been demonstrated and ask them as which test cases can be considered as passed.  
10. End the UAT by saying "It was a pleasure demonstrating it to you "

After the UAT 

1. Work on all the Observations and triage results so that they do not occur again. Inform the same to the client 
2. Send a completion report to the client and obtain a sign off from him so that the module can be delivered to him on time

In short taking part in UAT is a wonderful experience.Some clients are knowledgeable and by dealing with them one tends to think in all directions while approaching functionalities . Some clients are aggressive in nature and by dealing with them one tends to improve his\her people handling skills. Some are a combination of the two which is very difficult to handle. So UAT does tend to improve ones testing skills.

By trying out these above mentioned practises UAT does become a wonderful experience. In my experience I always look forward for UATs.

Hope I was able to throw some light on UATs. More on my next post

Till Then,
Cheers from Sai :) 

The V model

In this post I will be discussing an  important SDLC in testing that is used in the  industry.

The V Model 

The picture above describes the V model. The left arm of the V represents the waterfall model and the right arm represents testing for each phase of the  waterfall model. This model is not named  only by the shape  it forms but  becuase we do only Validation here so it is called as the V model. In the model if both Verification is also done then then the model is called as the V-V model

I assume that the readers know the waterfall model   and I will be discussing each testing phase


Unit Testing :  This testing is done by the developers. In this testing  the developers test each component of a module seprately to verify if the component is working as it is expected

Integration Testing : In this testing the testers verify if different components of the same module are synchronized with each other and are working as per requirement or not.

 System Testing : In this testing the testers verify if the subsystems of the software systems are working together or not


In the industry the Integration Testing and the System Testing are combined together and they performed as  System Integration Testing (SIT) , since they are almost similar in function

User Acceptance Testing:  This is the final phase of testing where the  software is shown to the client to check if the software meets the requirement or not.

The issues and the comments given by the clients are taken up as Observations  or Triage Results  and based on the complexity of the observation  a Change Request (CR)  is raised and the changes are made .

The major advantage of this SDLC is that Testing exists at all phases of the life cycle, and this life cycle is not only applicable to a waterfall model but can be used with other models as well such as the Iterative, Agile and Rapid Application Development Model.

Each phase of testing  has an Entry and Exit Criteria

The Entry phase  for Unit Testing  is

• When development is completed 
• When there is no NC(Non Compliance) for the coding standards

The Exit Phase  for Unit Testing  are 

• When all bugs have been fixed 

The Entry Phase  for SIT  are 

• When Unit Testing is completed and all bugs have been fixed 
• Build has been deployed in the SIT Testing Environment 
• Test Cases Written  and all the test cases have covered the Requirements and approved from the development team

The Exit Phase  for SIT  are

• All bugs found  in SIT phase have been fixed 

• SIT Report  should  be published  

The Entry Phase  for  UAT  are 

• SIT should have been completed 
• Quality audit should have been completed  with no NC 

The Exit Phase  for UAT  is

• Requirements must be met
• Final Sign off from the Client 

It is genrally considered a bad practise if there are defects and bugs present at the UAT stage.  Ad Hoc testing and a sanity check should be done after completing SIT and before starting the UAT phase

Thus I hope I was able to give a small idea about the  V model. More in my next post. 

Till Then 

Cheers From,

Sai :)

Pair Testing

 

Today when I was reading something on the internet, I cam across an area called Pair Testing. Being curious, I started reading about it. I found it interesting and I thought of sharing it here.

Pair Testing is a Testing process where two people do testing at the same  computer or  terminal.One person will be handling the computer and the other discusses, reviews various scenarious and cases It involves a tester and a developer\business analyst. It is genrally conducted as a Exploratory\Ad hoc testing . It is very helpful especially when the business requirements are stated poorly or has ambiguities in it.  Pair  Testing is a methodology used in Agile Software Development.  The most interesting fact about this is that it is only 15% slower than the conventional testing method .

The advantages of this testing is as follows:-

1. The domain knowledge of the analyst and the testing skills of the tester go hand in hand. Hence many bugs can be found when compared to the tester and the analyst\developer working alone
2. Testers get to learn about the software application and the business workflows explicitly 
3. The Business Analyst and the developers learn to think in all directions as how a defect can creep into the system, various vulnerabilities,risks etc  Hence this inturn improves the unit testing and the cost of coreecting bugs reduces drastically 
4. The team inturn understands the requirements better 

When pair testing is to be Used ?

1. When the software application\requirement  is to be understood within a short span
2. Can be used to train freshers in testing domain 
3. Sometimes while testing alone, testers find a bug that keep ocurring randomly. With the help of pair testing the developers and the testers can find the pattern of the bug and  can fix these bugs accordingly 

When Pair Testing is not to be Used ?

1. When a structured testing is being done 
2. Automation Testing 

Preparing for Pair Testing

1. Two people should voluntarily form up to do pair testing. They both need to be in the same wavelength and their skills must be complementary to each other 
2.  A work station with adequate seating space for two and an undisturbed environment

When starting for Pair Testing, the objective must be clear although it is more like ad hoc or exploratory testing such as getting requirements clear, understanding the software system, finding patterns in defects etc. These need to be clearly stated for starting the pair testing

While executing the pair testing one must execute the testing and the other must conrol, make note of the behaviour and monitor the system. The users must swap roles periodically.

After finishing pair testing the observations must be recorded, bugs must be raised and taken up accordingly.

In a nut shell, pair testing is an interesting and an effective way of working and one should use this whenever he\she has the opportunity to use it.

Types of Testing

Testing consists of two parts:-

1) Verification: Building the product right

2) Validation : Building the right product

The major difference between the both is that Verification not only helps in finding the defect but also helps in finding out the location of the defect. On the other hand Validation only helps on identifying the location of the defect.

Secondly Verification is a static testing i.e. it mainly involves reviews such as review of design, requirement, code etc. whereas Validation is a dynamic testing as checking whether the software is doing what it is suppose to do and is also not doing what it is not suppose to do.

Both are equally important and need to be done during the SDLC process.

Using both Verifcation and Validation there are different types of Testing can be done and are classified as follows:-

Based on the Knowledge about the code Testing can be classified as:-

Black Box Testing: The Tester has absolutely no knowledge about the code. The Tester is expected to test the software based on the requirement given to him. Most of the testers in the software industry are black box testers.

White Box Testing: The person testing the software has knowledge about the code and how the software has been developed. This is genrally followed by the Developers to conduct Unit Testing.

Each of the Testing have their strategy to follow which we will see below.

In Black Box Testing the following strategy is followed:-

1) Boundary Value Analysis: : To test  a field\variable in a software the range of the field\variable will be given. The field\variable should accept values within the given range. So this testing will check how the software will behave if a value is given below the given range, well in limits with range and a value above the given range.
 eg: A Mobile number field is to be checked. It is said that the mobile number should be of 10 digits and should start with 9. So the range here is defined as from 9000000000 to 9999999999.  So the system should accept a value within this range and should not accept values that is below or above the given range. Also looking into ASCII character value wise it should take those ASCII inputs that are from 0-9.

Boundary value analysis should also be used when there are overlapping of ranges to check  those values that fall in the overlapped region. 

2)Equivalent Partition Method: This strategy is used from the user perspective if the user would have to make a choice from a list of menu in a menu driven software and check if all the choices are working and whether the software system is rejecting an invalid option or not. In my experience I have used this predominantly in CUI programs where menu driven option is highly used  and checked how the software behaves . It is supplemented to the boundary value analysis

3)State Transition Technique: This strategy is followed if a software system has various states and a state transition diagram that shows as how the software system moves from one state to another. eg: Let us consider an online transaction to buy a product. There exists states such as
a) Submitted: When the purchase order is submitted to the vendor
b) Verfication: When the card details are verified.
c) Sold: When the transaction has been made
d) Delivered: When the product is delivered to the client
e) Failed: When the transaction has failed

As seen in the above picture, the transition diagram will be as follows. So for a tester to test the software system following the above diagram, he would have to have two test cases, one for when the transaction is successful and the other for testing in case of failed transaction

4) Ad Hoc Testing: This is testing is an exploratory testing which is not documented or planned. The tester would explore the software to find the presence of bugs, vulnerabilities and risks. It is an informal way of testing and does not have any specific technique to follow. One would require good observation, high analytical skills and observation to perform this test.

 Now that I have now discussed about Black Box Testing I would now discuss about White Box Testing .

In white box testing as far as my experience , I have used a method called
Control Flow Path: Through this strategy, a coder finds the number of if else paths, loops etc and ensure that the program executes each of the control flow path atleast once
Eg:

Looking at the above code snippet we have three paths.
1) In Case 1 when the number is odd
2) In Case 1 when the number is even
3) When the choice is not 1.

Hence we would require three types of test data to test the above code.

Testing Based on Requirements 
So far I discussed about testing that was classified based on the knowledge of the tester about the code. In this section we will see the testing that has been categorized based on the requirement.

Based on the Requirement Testing can be classied as
Functional Testing:  This testing is done based on the business requirement and the business workflows that are to be followed

Non Functional Testing:  These testing  study the basic charactersistics of the software system. They are further classified as follows:-
1)Performance Testing:  This testing is used to determine the performance level of a software system. eg: To check if a software system can handle X users with Y amount of data being fed into the system with Z concurrent tranaction at any point of time.  The basic attributes that are determined during this test are  Throughput, Response Time, Turn around Time,Load etc.
 
2) Load Testing :  This testing is done to determine if the software system can handle the expected load during real time execution

3) Stress Testing :  This testing is done to determine how the software system can handle when large volumes of unexpected data are required to handle by it .

4) Structural Testing:  This is used to test the skeleton or the basic architecture of the software.  The disadvatge of this testing is it does not check whether the software system's functionality is working correctly or not.

Thus I hope I was able to give a clear picture about the given topic. More in my next post. Till then
Cheers From,
Sai :) 

What is Testing ? Why Testing ?

In my previous post I gave my experience as what it is to be a tester. But have you all wondered what is Testing ? Why is Testing done in Software Developemnt ?

In SDLC Testing is a significant phase.

What is Testing ?
* Testing is a risk reducing activities

* It is mainly aimed at reducing faults and bugs in the software

* It is used to determine whether the requirements have been met

* Testing is not a process that happens at the end of development but it is something that starts right from Requirement Specification

* Testing is a way to measure the quality of software produced

Testing is completely different from debugging.

Testing is a process of finding the presence of faults and defects. While debugging is a process of correcting the faults and the defects present in the Software. Debugging is done by the developers while testing is done by testers.

By the above statement people genrally wonder why there are testers seperately? Cant the developers do the job of a Tester ?

A Team generally consist of testers seprate testers because the general pschycology of a person is to not accept faults on his\her creation. So if there is a person who was not involved in the creation of a product, he\she will not be biazed and can raise more defects and bugs that are actually present in the Software. The aim of testing is not to show that software is doing what it is suppose to do, but to show what the software is doing what it is not suppose to do. In short the aim of the tester is to raise as many defects and bugs present in the software as possible in the early stages of development so as to improve the quality of the System.

The Significance of Testing in Software Development is
* Rigourous testing and documentation is important to reduce the risk and defetcs in the software being developed

* It is not a phase that comes at the end of SDLC but however it is a phase that satrts right brom the start

*The advantage of testing is when the process raises defects and bugs at the early stages of developement thus reducing cost of development and improving quality

* Testing shows only the presence of bugs and not the absence. So it is genrally considered that a bug free product is not possible

Before I move on I would like to discuss about Quality

What is Quality ?
There are different definitions given by differnt bodies. But I like this definition.

It is the degree to which a software adheres to the explicitly and implicitly stated requirements.
eg:- Let us consider a web application for say for railway reservation. We say that the web application is of good quality when:-

1) The web application has a easy to use user interface
2) The web application meets the user requirements
3) The web application is a very low response and turn around time
4) It can handle umpteen users and conduct multiple concurrent transaction and provide the same response time to all its users
5) The application handle the unexpected huge amount of load it receives from the users
etc.

This gives a small picture as what is quality. There are various quality models that i will discuss soon.

I will now discuss the next section as

Why do Testing ?

* A Bug free software is never possible. As we humans are never perfect and as I said testing shows the presence of defects and not its absence. Hence a bug free product is almost impossible. But we need testing to remove the defects that are present

* A software that posses bugs can lead to problems:-
a) Loss of money.
Let us consider a net banking application for fund transfer between two savings aacount. A bug existed in updation of the database which was never found. Just imagine how much will the customers lose if such an application is released

b) Injury to health and even death:
I remember reading once that there was a cancer curing machine developed that was controlled by a software. The software controlled the amount of radiation that will be exposed to a patient. The software had a defect and the machine exposed huge amount of radiation to the patients which inturn caused death to many of the hospital's patients .

c) Wastage of time.

* To improve quality of the system

* To check if the requirements are met


One must undderstand the common causes of defects that happen in SDLC. They are as follows:-

* Human errors. This happen due to tight schedules and dealines. A team might have the best programmers and developers in the world, but under tight situation errors and mistakes are prone by anyone

* Complexity of the technology and solution used and provided. In such complex scenarios many loopholes tend to exist which are to be found by the testers and they need to be blocked.

* Programming errors which cannot be avoided as no one is perfect and working on tight schedules makes it happen.

* Wrong programming styles used

* Poor requirement captured

I hope this article thre some light on testing. More on my next article.

Till then Cheers From Sai !!!

What is it to be a Tester ?

Hi Folks,
This is my first technical blog and the first post on my blog. Now before I go further I would like to give an Introduction about myself. I am Sainarayan, working as Test Engineer at Wipro Technologies in  Gurgaon. I am an alumni from Indian Institute of Information Technology-Allahabad. I have around 7 months of  work experience and like many others, I am new to testing.  Like many even I was also skeptical when I became a tester, but now I really enjoy this domain and I am pretty passionate about it and I would like to share my thoughts, views and expereince in software testing and allied areas particularly with college students in order to remove the myths about this domain and to show them how interesting this career can be.

So with my small introduction, I will now tell you about this field. Software Testing as a  career has a lot of advantages. They are as follows :-

1) It is a highly analytical job. I would say it is even more analytical than a developers job because while testing a module you would have umpteen number of paths to follow with a huge amount of test data. You cant follow all the paths, but you would have to find as many bugs as possible.

2) A Tester does not have to debug the defects. It is the developers job and tester has to keep finding bugs. So in short you dont get stuck with a problem for days and the work goes smooth.


3) A tester can work across various industrial domains. eg:- A tester working on a software project on a banking domain can easily shift to a project on a telecom domain with very little preperation. In short it is a very flexible job across various industies 

4)Tester gets to know the workflow of the entire software system, unlike in case of developers where the developers know only the workflow of the module on which they are working, the in port and out port of that module. 


5) A tester does not need to learn new technologies and programming languages that frequently as compared to that of a developer. Testing does involve scripting  but that is only in the automation testing which I will discuss later . However the tester needs to be acquainted with the quality standards in the industry 

6) A tester gets paid as much as a developer or even more than a developer
 
7) Software Testers have control on the release of a Software. If a tester does not approve of a release of a software, it does not get released into the market. However if a bug is found in the software after its release, " The Tester is responsible " 

8) Testers get to  interact more with clients and explain the softwares to them particularly through Alpha, Beta Testing and User Acceptance Testing. So those who would like to interact with clients can think about it as a career. 

One thing I like about testing is that it converges towards Quality Control, Quality Assurance etc. . Achieveing a quality product is more challenging that to propose a software with a good idea, for a software which has a poor quality can be disastrous and can even destruction to life and property. 



I hope you have got an idea as to what it is to be a tester and how the Software Testing field. More on my next topic. 

Till then Cheers from Sai