Handling Software Product Support

Friends it has been long time since I posted last. In my opinion two most difficult fields in software industry / SDLC are “Software Testing” and “Software Implementation and Support” as both are customer facing. In this post, I am sharing my experience of software product support industry till now as to why I consider it as one of most difficult field of IT.

Software Product support is not an easy task and it takes lots of time to become productive in this field. Following are the major reasons –

1. Vast and complex nature of software - Any product implemented in a particular organization is certainly of a very vast and complex nature as they are automating major processes of the organization.

2. Customizations in standard product – Every organization has its unique needs and processes. Thus while implementing a standard industry product some customizations has to be done in standard product which implements the unique needs. This adds to the complexity of the product.

3. Change in requirements – There are sometime frequent changes in requirements and this tampers/somehow disturbs the original information flow of software. This in turn introduces new issues in software.

4. Volatile nature of software – Remember software’s are volatile. An issue which is encountered at customers end might not get replicated at support environment at all. There are also incidences that a incidence occurs just now might not occur next moment.

5. Expertise and problem defining capabilities of customer – This is also one of the major points contributing to difficulty of the job. Some customers are intelligent enough to explain the problem and resolving the queries for such is bit easy as compared to customers who are not intelligent enough and are not sure of what operation they have performed. Also there are customers who are technically sound it is easy to explain / resolve their queries. Also it is easy to make them understand the complexity and technical aspect of the problem.

6. Nature of customer – Understanding customers is very difficult. Customers are after all humans and as there are different types of humans on earth there are variants in customers too. Some customers can control there emotions and some cannot. Some report issues after doing every workaround and some don’t. Some want there work to be done on priority and does not want to wait at all and some can wait. Like wise there are as may categories of customers as there are humans on earth. A software support / technical support engineer has to handle them all.

In the coming post, I will deal with handling issues while providing support

ERP … the future

Friends, a post after long time. Here I am again sharing my experiences while working on ERP products. This post can be boring but since this is a theoretical concept so cant help in that.
ERP or Enterprise Resource Planning, as the name suggests is a software package designed and developed to plan all the resources of an enterprise effectively. These resources can be Financial Resources, Human Resources, material resources and others. A ERP package software addresses the enterprise needs of an organization by tightly integrating the various functions of an organization using a process view of the organization. The activities supported by ERP systems include all core functions of an enterprise, including financial management, human resources management, and operations. Major reasons organization going for / advantages of an ERP product are –
- Integration of interrelated information.
- Integration of end to end business processes.
- Standardize and speed up organizational processes.
- Reducing complexity.
- Centralized information source
- Security
Interestingly, above are also the points why organizations are reluctant in installing the ERP system in there facilities as because of these reasons results in decrease of departmental myopia and also the habit of putting work on others shoulders.
We will try to understand all the above points by an example. Visualize an industry process of manufacturing, storing (Inventory) and selling of an item. Now we start from back, a sales person enters a sales order in the system for item X with quantity Q then the inventory in charge should come to know that Q is committed to sales for item X. Further consider that there is minimum stock which is to be maintained for item X and if processing of this sales order decreases the inventory below the minimum stock quantity then the production in charge should be intimated to start production of item X. in turn purchase department should be intimated to purchase the required raw material. Below is a diagram depicting this flow –

Coming back to above points, ERP automates, integrates this information flow and the business process as well. It also standardizes and reduces the process complexity. Above all, all this information is stored at centralized place and is secured by user privileges.

A quick point on testing ERP software, apart form the normal functionality a tester has to test the business process and the integration of the information among the interrelated modules.

Spice QT-66 Usability Issues

Friends,

Nothing much to write about in this post as this is just a small sharing of information in reference to usability of mobile phones.

Recently, I bought Spice mobile QT-66 just two months back. This is the first time I am using any phone other than Noika. While using spice one, I observed two unusual things both in terms of normal usability and also when compared to Nokia devices. Observations are -

Whenever I disconnect a call without attending it then usually in Nokia devices this goes into RECEIVE CALLS but in my spice device the screen displays MISSED CALL and the entry also goes into the same option (MISSED CALLS)
Second observation is regarding the MESSAGE functionality. Whenever, I reply/type a message and then I opted to end the message screen by pressing the END key then the message gets saved into the OUTBOX folder. Usually it should be in DRAFT folder as per my usage of other devices / messaging software’s

Comments awaited on this…………………

ICICI Bank ATM bug … Try it!.............

Friends, apologies as I am updating the blog after a very long gap of almost 2+ months. Anyways, just thought of sharing some interesting observation I found today. (Apologies again as being a tester I would have found this earlier but no body tries to play with their own money so neither did I : ) )
Recently I went onto an ICICI bank ATM for doing some transaction. I noticed one interesting bug over there. I want all of you to try that only once because if you try it for 3 times consecutively your card will be blocked and I am not responsible for that. Anyways, here is what I noticed –
PREREQUISITE - You must have changed your ATM PIN once.
1. Insert the card
2. Enter the old PIN , the one provided by the bank initially
Notice that you will be presented the transaction selection screen
3. Select any transaction, say balance enquiry / any other from the available options
Notice that now you will be prompted that you have entered wrong PIN and the machine will ask for the correct one.
4. Enter the correct PIN and then you will proceed towards the completion of your transaction

Comments awaited on this obsercation as to whether this is a bug OR not . In my opinion , its a high priority Low sivierity BUG

Amit

Google Buzzes - minor bug

Recently, I was posting a link on Google Buzz and I noticed one interesting thing that “Add Link” button gets activated with any key event. Normally the buttons of such nature gets activated when user enters any character / text / number in the respective text box but this button in Google Buzz is somewhat different OR I should say a bit deviated from the generally expected / implemented functionality. Here are the steps to reproduce this observation –

Browser – Mozilla Firefox
- Navigate to Google Buzz
- Click on the text area
- Click on LINK hyper link to insert a link / web URL
- Click inside the text box and then press WINDOWS / CTRL + c / CTRL + v / Any other CTRL key combination / Any ALT key combination like ALT + f

Actual Result – The ADD LINK Button gets activated

Sign Out.. OK... But when did you asked me to Sign In

Bug on Airport Authority of India website

This is first post for July month also I am posting after a gap of almost 15 days. With this post I am sharing some of my finding (BUGS) while surfing the internet.

Recently, I was browsing the website of AIRPORT AUTHORITY OF INDIA and observed two interesting bugs both functionality / usability wise

Bug # 1 – SIGN OUT function (link) available while searching for airports (User is not logged in)

Steps –

- Launch the site http://airportsindia.org.in

- On the left pane menu , click on passenger > airports > all airports

- On the map available, click on any airport for which flight schedules are not uploaded eg. RAIPUR

- Click on ‘Flight Schedules’ link – This step will take user to search flight page (URL - http://airportsindia.org.in/ServletController?action=site_flight_select)

Actual result – Notice the ‘Sign Out’ option available. User has not signed in / not asked to sign in yet. Clicking on this ‘SIGN OUT’ link navigates the user back to the home page. See the screen shot below

Regional bug

Title of the post is inspired from a fellow tester Mohit’s blog. Thanks Mohit for inspiring !....

This post is an extension of my previous post Bugs found in routine internet surfing – 1 where I mentioned bug found on a local newspapers website. Now this Dainik Bhaskar’s (A Hindi Newspaper) websites irritates me a lot as recently I found another high priority defect related to the navigation on the website. Before reading further I request you to refer my previous post for more details on the previous defect. Now here is the latest bug –

NOTE - Before going further more , please note that it’s a Hindi newspaper.

Bug > High priority and medium severity (As per my perception)

Short description – News Paper Website missing with the value of one city in the drop down on the respective states home page

Steps –
1. Open the URL www.bhaskar.com and click on States TAB on the home page
2. Click on Madhya Pradesh and click further on the Madhya Pradesh link (This steps will take you to URL http://www.bhaskar.com/mp/ , you can directly hit this URL also)
3. Navigate down to the drop down with value “select city”. Yellow highlighted portion in the screen shot below-




Actual Result – There is no value saying “Gwalior” , however when the user types in http://www.bhaskar.com/mp/gwalior/ in the address bar s /he is redirected to the respective page.

there are lot of other GUI defects as well

Thanks & Regards,
Amit

Some common scene in software testing

After a long time, I am posting something. Actually in the past days I read some blog posts and was collecting ideas for my blog. So here I am sharing my views on present trends -

Scene # 1

Recently I was having a discussion with my colleague and good friend Sudarshan about the testing process followed in big companies (No need to name any one !...). Our debate turns towards the type of different types of test cases , I said the possible types can be Unit test cases (prepared & Used by developers), functional , integration, system / system integration , regression and UI. To my surprise he added some more terms which I never heard and one of the interesting term was GROOMED test cases. He explained me that groomed test cases are the test cases which contains everything defined in proper way objective, steps, test data, expected results to name a few. I was amazed after hearing this new type and thought that what I studied is wrong OR what ? . As per my opinion a test case should contain all these necessary elements and only after that it can be called as a test case so where this groomed term came in ??

I could imagine a interviewer working in big company who would have asked this question to a 3-4 years experienced candidate and giving feedback that he is lacking basics terms. Is this a basic / industry standard jargon.


In a recent blog post from one of the very senior member in testing community I read his predictions about the future of software testing industry. I appreciate his to the point predictions that testing process will become more complex and companies will demand more and more from testers. He also said that in order to stay in race testers need to distinguish themselves from the crowd. I agree to all this totally. What I want to add is testers should concentrate on gaining expertise in the respective technologies / domains they are working in also need to focus on the industry process which is catered by the software systems. But I do have some doubts coming in following scenes –

Scene # 2

Testers are expected to know maximum technologies UNIX , SQL …….. do companies utilize these skills properly. Recently one of my fiend joined a company as a Test Automation Engineer (Obviously he was interviewed with series of automation tools questions) but the work he was put on is a big question mark. He was put on manual testing / reporting and his manger told him to understand the product well for next few months. Result he is frustrated and now thinking to switch again in just 6 months.

Scene # 3

Almost in every interview testers are expected to know SQL , some questions related to this are put on. The most important in JOINS. They are being asked to write some queries on this. But tell me seriously in reality how many testers really writes such queries while testing the product/application. Consider a scenario where a tester has started working on a project containing 100’s of tables which even the developers don’t know then would you like a tester to write JOIN queries… in reality developers use to provide the queries to the testers initially and it depends on the testers perspective to learn the process OR not. It hardly matters in reality. And again many people are rejected in the interviews on the basis of these questions.

Scene # 4

This is really very amusing , I am into manual testing and in my CV/Resume I have mentioned this very clearly in the header line itself. Although I have very little knowledge about automation tools but no where I have mentioned QTP(in the projects as well). Now in the interview , the interviewer asks me # 1 Do you have knowledge of automation tools , # 2 have you worked on QTP/Any automation tool in any of your project. Now # 1 is OK but what about # 2 , has he gone through my profile OR he is taking interview just for the sake of taking and would find one reason to reject me. Also how did the recruiter shortlisted my profile

Anyways, there are many more !..................


Happy testing friends

Functional & non functional requirements

Functional & non functional requirements

Today’s post is about ‘Functional & non functional requirements‘. I found lot of articles on the internet explaining what are functional and non functional requirements in reference to a software system. Also this is a common question asked in software testing interviews :)

In all software systems there are basically two types of requirements namely functional requirements and non functional requirements.

Functional requirements of a software refers to the stated features of the software which it should have OR it should do in order to achieve satisfy the business needs. Functional requirements are business requirements which a software should have in order to satisfy the user needs of the business. These requirements describe what a software should do and how the user should use it in order to achieve a particular business flow / functionality. Technically functional requirements divides the software system into different modules with respect to the various operations OR logical group of operations and defines the attributes/features of these modules. As stated above, functional requirements satisfies business rules and changing the functional requirements will definitely change the functionality of the software systems.

IEEE defines functional requirements as -A system/software requirement that specifies a function that a system/software system or system/software component must be capable of performing. These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs.

Typical functional requirements of a software system can be –
- Business Rules
- Transaction corrections, adjustments, cancellations
- User authentication and authorization
- Certification Requirement subject to certification compliance.
- Legal or Regulatory Requirements

Non functional requirements are other set of requirement that a software system should have so that the system should be more usable and reliable specifically. Non-functional requirements specify all the remaining requirements not covered by the functional requirements. These requirements are more related to / cater to user rather than to business rules. These are not the tasks that will be performed by the system instead these are the quality standards which are good to have by the system and thus does not effects systems functionality. These are not the mandatory requirements of the systems but in order to be a good software from users perspective it’s good to have these. Often these requirements are used to compare the products of similar functionality for example there are lots of total banking automation (TBA) solutions available in the market but decision of choosing a software depends on how reliable and secure a system is. Typical non-functional requirements are:

- Performance - Response Time, Throughput, Utilization,
- Scalability
- Reliability
- Recoverability
- Maintainability
- Security
- Usability
- Interoperability
- Compatibility

Appraisals

Friends,

June has started and we all are waiting for the appraisals, Our HR is busy with this too. Recently I came across one post from Parimala on her blog “Curious Tester” under the heading “Inferno around Designations”. This gives me idea of sharing my views on this all time burning topic 
Now they say to get a good hike you need to change organization some others say that to get a mere 30 % (let’s assume its industry standard) hike why should I lose my present appraisal as I can expect more higher offers after this appraisal. Don’t worry both these guys are right and I am not I am not denying any of these arguments. I just want to put my standpoint on both these arguments whether you are / you are not / you are waiting for changing the job first think of learning opportunities in the present / future company. In my opinion recognition of work is more important and when you are recognized you will definitely get a good appraisal in present organization while if your manager does not recognize your hard work and keeps on counting your mistake don’t wait for the appraisal and start looking for change since you can’t expect a good hike. All you will get is a mere hike while you can get much more when you change the job. Talking specific to TESTING, in many organizations where there is no separate test manager appraisal is done by project manager who is basically guy with development background. In such situations the appraisal depends on the feedback of other guys in team which is very harmful as the feedback would be taken from dev guys mostly. The appraisal here depends mostly on your relationship with development team and you might not get rewarded according to the efforts you did.

On the concluding note, my standpoint is when you look for change you should analyze on the learning opportunities in the present and future organizations as well. In case there is not enough learning opportunities then it’s better to look for change because professionally nothing is gained. After all software industry is a very dynamic and your learning matters a lot when counted with your experience, I have seen such examples where a person coming for a reputed company having years of experience asks how to take screen shot in case no tool like SNAGIT is available.


Wishing a very good future and appraisals to all readers !...................


Thanks & Regards,
Amit

Peer Reviews

Peer Reviews

Welcome friends , new week has just started. Monday blue’s are on full swing. Let’s start this week’s blogging with a less talked topic “PEER REVIWES”

What is it ? In simple language this term is used to describe a review process of the artifacts /documents by the peers in the team wherein the author of the document presents it to peer members in the team with the purpose of getting feedback in order to improve the document before making its final version.

Process of peer review is not very tedious where the document author presents the document to the group of reviewers who are members of same team and explains the purpose of the document as to what is the document, objective and details about the document and ask for the feedback on the document. From the author’s point of view it’s good to have a checklist ready at his end before submitting the document just to reduce the reviewing time and avoid small mistakes.

Purpose behind this activity is can be –
- Validate the correctness of the document.
- Validate the coverage of document with respect to purpose for ex. Peer review of a test plan/strategy document should verify that the test plan/strategy is in accordance with the project/product for which we are doing testing and it is covering each and every aspect of testing which can be done/carried on.
- Validate the conformance of the document with respect to the process followed in organization, standards of the organization and client needs if any.

With respect to software testing , there are many documents for which we can conduct peer review such as test plan, test strategy , test cases and scripts and other such documents. Benefits of the PEER REVIEW process can be achieved only when the review comments are documented and in turn implemented properly. Also as a suggestion it should be done be senior members of the team who have good command over the product/system and have good domain knowledge

Ad-hoc testing and Exploratory testing

Today’s post is just a MICRO blog about Ad-hoc testing and Exploratory testing

These two terms are often used interchangeably by the development guys. I wonder senior dev guys in my team don’t even know difference between black box & white box testing. Anyways coming back to our main topic both ad-hoc and exploratory testing

- are system testing techniques where in we test the whole software system.
- are undocumented form of testing in the sense that the test we perform are no formally documented. That is the scenarios in this testing are apart from the documented test cases.
- are informal testing techniques performed at small scale generally after the completion of formal testing OR when we have less time.

The only difference between these two is that in order to perform Ad-hoc testing a tester should have domain /product knowledge while no such knowledge is required for exploratory testing, success of ad-hoc testing totally depends on the knowledge and experience level of the tester. We can understand exploratory testing going be name , it means to explore the system with the intent of learning and also to find bugs. Main aim of tester performing exploratory testing is to get knowledge about the system and report bugs after getting them validated from a person having sound knowledge of the product. While the sole purpose of ad-hoc testing is to find bugs in the system as the tester already have the necessary knowledge about the system/product under testing. One important implementation of ADHOC TESTING is when we want to test the application beyond the documented OR obvious tests and also we may want to focus on most critical areas of application in case we have less time for testing and therefore can’t prepare test cases. For exploratory testing one such implication is when we do not have enough documentation available and want to know more about the application so that we can prepare some formal document regarding the functionality of the application.

Positive, Negative testing and test execution

Ideal flow of test execution , some days before a friend of mine (a fresher is testing field) asked me about positive, negative testing and the flow of test execution and his understanding inspired me for this post. As per my understanding, positive testing is ‘Test to pass’ that is testing done to confirm that the system meets the specified requirements. In these types of tests we usually do not input invalid conditions and main concentration should be on finding out the defects/bugs by executing the system as per the normal functionality. Under this we concentrate on the written requirements and normal flows and validate the system against it. In other words we validate that the system is working as per the documented requirements.

Coming on to negative testing, it is ‘Test to break’. Now that we are done with the normal testing we try to break the system by trying negative scenarios on it such as invalid inputs, unusual load and other negative scenarios so as to know the behavior of the system with such conditions. Suppose that a website is expected to have load of 1000 hits at a time then in negative testing we may try to overload along with the abnormal communication conditions.

Coming on to the test execution part, I follow a thumb rule that as a tester my job is to first validate that the system is working as per the written requirements (TEST TO PASS) and then after this I should try the negative scenarios (TEST TO BREAK). Remember, our first job is to execute the documented test cases since this is what we have agreed to deliver to the client and these are the test for which client is expecting the test report. So the order of execution should be first the positive tests and then the negative tests that is after positive testing we can try our hands on some undocumented testing (Ad-hoc and exploratory testing)

Requirement traceability matrix (RTM)

Requirement traceability matrix (RTM) in simple words is a document containing the requirements mapped with the test cases/scripts covering that particular requirement. it is one of the most important document created during a project life cycle and is very important in software testing activities. Going further RTM can contain more details like name and brief detail about the requirement, details of test case/script document which contains the test case(s)/script(s) handling the requirement, priority & severity of the requirement and also the verification status of the requirement (whether the test cases have been executed OR not) along with the status of requirement (Pass/Fail – requirement is catered in the software system and in fully functional without any bug). These details are not mandatory but definitely adds value to the RTM document as it provides complete picture about a particular requirement.

Creating RTM – there are 100’s and 1000’s of template available on the internet. Just pick one of them OR create your own. In a very simple way , you just need to create a table containing requirement ID (As mentioned in the SRS/FRS/Requirement Specification document) and test case ID of the test case in which this requirement is being tested. In addition to this we can provide other fields as mentioned above. Also we can create a single RTM document for both unit and functional/system test cases

Benefits – RTM is very beneficial in software testing as it –
- Track all requirements and whether or not they are being met by the test.
- Help ensure that all system requirements have been met during the Verification process.
- Above all it’s a very good tool from management and testers perspective as well. For testers , it serves the benefit of knowing how many requirements are covered and from management’s perspective it’s a tool from which they can gather all the required information pertaining to a particular requirement.

Mobile Application Certifications

There days mobile applications are on real boom specially after the entry of mobile platforms like Iphone/Blackberry/Android. As far as testing of mobile applications is concerned , a mobile app has to be tested on functionality aspects and on other aspects as well. You might have gone through my previous post mentioning major points of consideration while testing a mobile application. In this post, I am concentrating on testing the mobile application on other aspects. One such aspect is vendor certification testing which is done in order to get your application available on different app stores so that end users can download and use it further. Due to the boom and increasing number of mobile applications everyday different mobile technology/platform vendors have provided centralized places from where user can download the available applications such as Apple app store for apple, Windows Marketplace for windows, Blackberry App World for windows, Mobile Shop for BREW. These technology vendors have provided generalized tests, In order to place/release their application to users software vendors has to get them passed through these tests.

So far, following vendors have defined their test process and provided the test cases

- BREW – The process is known as ‘True BREW Certification’ and a set of test cases provide for this is known as ‘‘True BREW Test’ OR TBT in popular.
- Windows marketplace submission criteria for placing the application on Windows market place.
- Java verified program for J2ME applications.
- Symbian signed criteria for getting the application signed by symbian

All these above concentrates on general behavior, stability and functionality of the application. These are not at all related to testing of specific functionality but concentrates on general attributes which every application should posses.

Build Installation Procedure for Brew Applications

When a BREW application build is released for testing, it basically comes under two different folders as follows –

- Arm
- Win


ARM - This folder contains files which are to be loaded on actual mobile device. It should contain following 4 types of files

- .mod
- .mif
- .bar
- .sig

All these files are loaded on actual device for testing. MOD file contains the compiled code of the application for BREW handsets. MIF (Module Information File) contains icon, thumbnail etc of the application. This file is used by the handset to identify the application. BAR file contains resource files like images, text etc and SIG file is digital signature file which is unique for every handset, we can generate it by providing ESN/MEID of the handset. This file and is independent of the application but dependent on the handset.

These are minimum number of files needed to load and run the application on the BREW device. While loading SIG file name should be same as MIF file and the name should be in small letters. Generally the arm folder is renamed the same as MIF file and the whole folder is drag and dropped onto handset once the handset is connected to the PC through BREW apploader. Remember to power cycle the handset after loading the build.


WIN – The content of this folder is basically used when the application is to be tested on emulator. This folder contains minimum three types of files

- .dll
- .mif
- .bar

DLL contains compiled code of the app for emulator/simulator. MIF and BAR are same as above. The process to load the application into the emulator / simulator is as follows –

1. Copy this folder to ‘Examples’ folder of the BREW emulator / simulator which we are using (SDK 2.0.1/SDK 3.1.5) and rename the folder to the ‘Application Name’.
2. Rename the .dll and .mif files to the name same as the parent folder. Make sure that the folder name, .dll file name and the .mif file name should be same.
3. Copy the .mif file to the main folder ‘Examples’
4. Copy the device files / folder (Emulator) to the devices folder of the BREW emulator
5. Launch the emulator and then load the device on which we have to test the application.
6. Launch the AUT for testing.


Happy testing !.......................

Real time projects - 1

Friends apologies for a week delay in blogging but I must admit that I am running short of ideas. Actually , I am not getting expected comments on my posts and as result not getting new ideas. Anyways, for today I am just sharing one of the assignment I worked on. It was a testing project for a US based mobile marketing company …. Sorry cant disclose the name as I have signed NON DISCLOSURE AGREEMENT in the company where I am employed  .

In today’s blog, I am just sharing my experience working a project, different types of testing carried out and overall experience.

Now the project was testing of compatibility of a third party device (I will name this CON ) with various mobile devices. CON delivers contents to mobile devices through Bluetooth. This is a new form of marketing “Bluetooth Marketing”. The manufacturing company has deployed this device at various public places in US. These CON’s detects different mobile device (whose Bluetooth is ON) falling in its range (which is approx. 30 meters) and as soon as a mobile device comes into the range some flashy message is transferred to the device for example – DO YOU WANT TO GET SOME NEW WALLPAPERS FROM PEPSI or something like that. The mobile user has an option to accept/reject the request. Now there are two different cases –

Case # 1 – if the user accepts the request then he/she is provided with some free content which can be a wallpaper, animated GIF file, ring tone, video, flash, HTML/URL OR a simple J2ME application and also some paid contents.

Case # 2 – if the user rejects the request then the information of the user (BDA/COD details of the device) is passed over the network to other CON’s so that if the mobile device comes into range of some other CON then no request should be send.

Coming to the testing part , testing activities includes –
- Interaction between the CON and the mobile device whether CON is able to detect the mobile device , able to communicate with the mobile device, able to transfer the contents
- Compatibility testing of the mobile with respect to the various contents delivered.
- Usability of the various contents delivered on the mobile device.
- Functional testing of the J2ME applications.

Addition to this there was a web interface provided by the marketing team which contains pictorial representation of the CON’s and the devices surrounding them (Off course blue tooth of the mobile is kept ON otherwise CON would not have been detected it). This web based tool was programmed to display the details of the surrounding devices and also to transfer contents to these devices in case a device rejects a request by mistake.

The concept ‘Bluetooth Marketing’ is still very new and it was exiting working on this project as I tested almost 300 + mobile devices of various carriers in US/UK, moreover all the testing part was done on DeviceAnywhere (DAW) platform. Overall this project was a good learning experience in terms of knowledge of new mobile devices (BREW/PALM/Blackberry/WINDOWS platform). Above all the client was very cool and does not pressurize for work which was the most good part 

Writing effective test cases

Tips for creating effective test cases –

Today’s post it about writing effective test cases. Many times people use to jump on to test case creation just after reading the requirement which is not the right way. In this way your test cases will be very limited although covering the requirements. Here are points we should follow while writing test cases –

# 1 – Review the requirement document fully . Study all the requirements of the module you are working on thoroughly and make notes. If possible try to get detail understanding of the requirements by discussing with the BA team members. It’s better to make a query log and document all the queries and corresponding resolutions and share it with team. This will help in developing team confidence on you and your confidence on the system to be build. This will also help in validating your understanding on the system.

# 2 – Do brainstorming, after reading the requirements discuss it with peer members. Make notes of this discussion. Such discussion will help in deriving more test cases which one might miss. Remember everyone has different perspective and such discussions can help an individual to find out more cases for testing the application.

# 3 – After doing the above exercises do not jump onto the test case creation part rather first prepare high level test scenarios in relation to the requirements. You may/may not discuss these scenarios with the peer members.

# 4 – it is advisable to have a “Test Case Checklist” maintained at your end containing the general rules to be followed while creating the test cases like naming conventions should be in accordance with what has been decided, spelling mistakes should not be there, some specific words that should/should not be used in test cases and so on. Many a times organization have such checklist ready in case it is not then you can maintain your own. Such checklist helps a lot while submitting the test cases for peer / lead review and saves a lot of review time.

# 5 – Once you are ready with the high level test scenarios then move on the test case creation wherein you can create test cases in the organization specific template mentioning the detailed tests steps, test data, expected results and other related details.

# 6 – Have a “Traceability Matrix” . In case your organization does not maintains it, maintain one at your end. This is for the obvious reason for mapping the requirements with the test cases. It will also help in finding out the left requirements and the redundant test cases if any.

Thumb Rule – Do enough , fast and effective paper work/brainstorming before moving on to actual test case creation.

Bug found in iGoogle

Friends, today’s post is in continuation of my previous posts “Bugs found in routine internet surfing – 1 “ . today I am sharing some bugs observed in igoogle

Bug # 1 – Count of the emails does not increments/decrements (REFRESHES) properly on deleting/receiving of emails

Preconditions – User should have added ‘GMAIL PREVIEW’ feature on its igoogle homepage.
Browser – Mozilla Firefox V 3.0.19

Steps –
1. Open the igoogle webpage and log into your account with a valid user name password. (URL - http://www.google.com/ig)
2. On the home page locate the GMAIL PREVIEW section and click on INBOX link
3. Note the current count of the emails (Is should be In format 1 - 50 of about 500)
4. Select an email to delete (by checking the checkbox against it) and click on DELETE button.
5. Observe the count now

Actual Result – the count of emails does not get decrements and it still shows the old count number. Pressing the refresh link / browser refresh button also shows the same count.

But # 2 – In some cases it has been observed that the email count increments / decrements by 10 upon receiving /deleting an email

Regression Testing and Retesting

These two terms are often used interchangeably by inexperienced testers OR experienced developers/PM’s who are not known to testing. Anyways, I am not pointing to them in this post but just telling the difference between the two terms.

First Retesting , it is the term which is used to describe the testing effort of verifying the bugs OR defects logged in for the previous build and taking appropriate action on them. By appropriate action , I mean to close/defer/reopen the defect. To be specific “Retesting” is a subset of “Regression Testing”. Coming on the super set “Regression Testing” , it is testing of the module(s) in which bugs where logged for previous build and also the interrelated modules just to make sure that the bug fixes has not introduced new bugs into the system and the modules are working fine overall. Regression testing has wider scope as compared to Retesting because in the former we are covering the whole module and also the other interrelated modules and not just concentrating on the bug fixes only.

Thanks & Regards,
Amit

Bug in Facebook

One of my close friend shared a bug in facbook. Have a look on the image and notice the contents inside the red rectangular box on the left side and botom right side

Usability bug on blogger website

Usability bug on blogger website

Description – Website is not consistent, there is no SIGNOUT option available on ‘VIEW PROFILE’ page

Priority – Low. (I am not sure how many customers reported it)
Severity – Medium

Steps –
1. Login to your blog with valid user name and password.
2. On the dashboard , click on the ‘VIEW BLO’ link to view any blog.
3. On the respective blog , click on ‘View my complete profile’ link to land on your profile page.

Actual Result – On the profile page there is no link to get back to the blog/dashboard page. User has to explicitly click the BACK button on the browser.

As per usability point of view this is an issue related to ease of navigation. Also there is no way by which a user can submit the issues which he find during his blogging / normal browsing of the /blogs & website

Software Testing is not an easy job

Testing is not an easy job as people think about it. Everybody from the project manger to developers feels that software testing is a easy job in which you have to just test OR validate the software against the written set of requirements and for this ask they write the test cases for it and execute them on the product. This is totally true but this is just one side of the whole picture. Every software testers primary job is to test the software and make sure that it working as per the requirements. But here is the twist for performing this task he has to –

- Have thorough knowledge of the system under development which can be as vast as knowledge of the different modules of the system how these modules interact with each other, data flow between these modules and many more things. In contrast to this developers are confined to their individual modules, they are more concerned with the output of their module and many times it happens that they shed of their responsibilities by saying “I am sending data properly and in desired format from my screen/module (Say Module A) but if other module (Say Module B) is not fetching it then it’s not my job” . At this note, testers job is to find out this integration defect and let them know what is expected so a testers should know the functionality of module A , module B and the purpose of integrating these modules.
- Testers need to have ‘End User’ mindset to test the software. They need to think in the same way as the end users uses the software. At the same time they need to follow the documented requirements only then they will be able to deliver quality product. So they have a dual responsibility of their shoulders.
- Moreover they need to have domain knowledge of the industry which the software is catering and the knowledge of the current process practiced by the client. As for developers this is not as important.
- They need to test the software on wide range of data as against small set of data tested by developers in unit testing phase.

So please do not consider testing as easy job !.................

Very very minor bug on blog site

A very minor bug on blogger.com

I am new to this site and have started active blogging just a month back. There is one minor defect which I observed on this website. When you post a new article/post on the website, on the bottom it says ‘0 Comments’ which is OK and can be accepted. But as you post a comment on the post the messages says ‘1 Comments’. Now are there numerous comments. There is only one comment so it should be ‘1 Comment’ OR even ‘1 Comment(s)’ is fine.

I discussed the same thing with my colleague a fellow tester he also agrees that ideally it should ‘ 1 COMMENT’ but then he also told me about his experience where he reported the same defect in one of the project but it got rejected with the comment “It is as implemented”

What’s your thought..

Thanks & Regards,

Amit

Bugs found in routine internet surfing – 1

Bugs found in routine internet surfing – 1

Just starting off a new series of post where I thought of posting the bugs which I found in the routine internet surfing. As I am new to blogging off course this idea came to me while surfing different blogs and thought of implementing it as I want to make a routine practice of writing blogs and making my blog popular. Anyways, just sharing two interesting bugs with you –

Bug # 1 > High priority and medium severity (As per my perception)

Short description – News Paper Website missing with the value of one city in the dropdown on the home page

I use to visit website on local newspaper “Danik Bhaskar” (URL - www.bhaskar.com) daily to look on some local news of the city I was brought up – GWALIOR (Madhya Pradesh). Now there is dropdown to select the respective city edition on the home page. But there is no entry of GWALIOR in this drop down. However when I select the state (Madhya Pradesh) hyperlink and lands on the state home page and look on for the available cities in the dropdown on this page , I am able to locate GWALIOR and on selecting it I navigates to the respective page (Home Page of Gwalior News)

Now as per my perception it’s a high priority bug for obvious reasons as the drop down on home page is missing a value and there is no way to navigate to the respective city’s home page form the home page. However all other values are present and user can navigate to other cities pages. It is medium severity bug because user has some other way round to navigate to the respective city home page.


Bug # 2 > High priority and High severity (As per my perception)

Short description – Wrong address info shown on the ‘Contact Us’ section of a company’s website.

Recently , I visited website of a company and found that the address shown in the ‘Contact Us’ section is confusing for customers. Actually, the address written was different and the corresponding Google map was pointing to a different address , though in the same city.

As per my perception, this is high priority and high severity defect as the user gets confused as to which address he/she should make correspondence to.

Just FYI, I sent an email to the concerned company and was amazed to see the reply of the CEO/Founder accepting its a bug.

End of this part, will keep posting if something new found.. till then … happy browsing and as always comments/suggestions are welcome............ .


Thanks & Regards,
Amit

We the TESTERS

Today’s post is about the pains of software testing industry. In my 4.5 years of experience I have not seen a company who treats testers as a respected team members. When It comes to testing, most of the company’s pay less to the tester as compared to developers. Testers are not the respected members of project team. Developers think that it is because of them testers are getting jobs. Yes its true because these people make mistakes very often. I have faced this numerous times that developers have given days from testing schedules. Developers take their own time , eats up testers time and then mangers expect that testing should be perfect and no bugs should be missed. I don’t know how is this possible. Further when it comes to any issue reported in UAT / by client these mangers come to testers asking how this happened and the developers just shed off the responsibilities by saying ask testers. Many a times developers spend whole day on some small issues and release the builds to the testing team at EOD expecting the results by tomorrow morning.

Come on give me a break we the TESTERS are equally important to developers, we too have families to support and spend time with …………..

Basics of Software Testing - 3

Friends, starting the first post of may about a basic document in testing “TEST CASE”.

Test case – A test case is one of the major document prepared while testing any software. Generally defined test case is document containing some precondition , steps to be followed, test data to be given (Optional as some tests may not contain any test data) , Expected results after performing the steps to be executed for testing a particular requirement. Thus a test case must contain following essential components –
- Test case ID / #
- Precondition.
- Objective of the test.
- Steps to be followed.
- Test data.
- Expected Result.

Apart from the above, some organizations include other heads in test case document such as –
- Defect ID
- Priority
- Type
- Requirement ID/#

Now coming on to details of above heads -

Test case ID is the unique identifier for identifying a particular test case. It can be number/alphanumeric as agreed upon.
Precondition is a state/condition which is essential to execute the given test case. A very-2 common Example if I am executing test case(s) for testing a login web page then the preconditions can be as follows –
- Browser should be installed and running on the PC.
- URL for login should be present.
Objective of the test case is the scenario what we are testing. Continuing the above example my objective is to test the functionality of the login screen. There can be another test case with the objective of testing the user interface of the login screen.
Steps to be followed are the detail sequence of steps to be followed while executing a particular test case
Test data is the data to be keyed in while executing the test case. Continuing the login screen example, test data can be User Name, Password.
Expected Result is the output/results expected after performing the steps as mentioned in “Steps to be followed” and with the test data keyed in.
Actual Result is the actual output observed after executing steps given in the test case. It may/may not differ from the Expected Result and it determines the status of the test case.
Status of the test case can be PASS/FAIL based on the actual result. It can also be NOT RUN/TESTED based on the execution status.
Defect ID is the unique identifier of the defect logged against the failed test case.
Priority of the test case is how important the test case is . It can be HIGH/MEDIUM/LOW or P1/P2/P3 depending on how critical that test case is OR how important the test case is. It is determined by the functionality/scenarios that the test case is covering.
Type of the test case can be functional, UI, database depending on the requirement the test case is covering.
Requirement ID is the unique identifier of the requirement which the test case is covering. The purpose of including the requirement is in the test case document is just to make out the each and every requirement is covered and also to determine that which test case is covering which requirement.

Based on the above, we can now design a generic template to write test case(s) which can be as follows –

Precondition :

Test Case ID
Priority
Type
Requirement ID
Objective
Steps to be followed
Test Data
Expected Result
Actual Result
Status
Defect ID

Some basic points while preparing/reviewing/executing test cases –
- Read the requirement document fully and get the full understanding of the requirements.
- First prepare high level test cases OR test scenarios describing the what we are going to test and possible different states of what is to be tested.
- After this move on to detail test case writing with the steps, test data, expected results.
- Have a checklist ready before preparing test cases this will help at the time of reviewing the test cases. This checklist should not contain details but should point out generic points applicable to all the test cases. While submitting the test cases for further review validate the test cases against this checklist and submit it along with the test case document.
- While reviewing the test cases, reviewer should also validate the test cases against the checklist.
- All the review points should be documented in a proper format. Avoid sending review points in the email instead document in a proper document and send it. A separate copy can be kept at a central repository. Apart from this, another advantage is that document can be amended further. As with email, the trail gets long and its very tedious to keep a track of it.
- While executing the test cases try to indentify the important test cases and prioritize them. This will help to identify test cases which are to be executed in ‘Sanity level’ testing on the forthcoming releases.
- Also try to execute tests with combinations of test data other than the documented test data.


END OF POST. As always, suggestions/comments are most welcome.

Thanks & Regards,
Amit

Basics Of Software Testing – 2

In my previous posts I discussed about the basic of software testing and bugs. Continuing the series, I would like to discuss about the software testing process followed in the industry. First we will talk about the software development life cycle , the SDLC. Be it any model followed in your organization all the models are based on the pioneer WATERFALL model which contains following general phases –
- Requirement Analysis,
- System design,
- System development / Coding ,
- Testing and
- Implementation & maintenance.

In brief , we analyze OR study the present system and get detail understating of the client’s requirements in context to the system to be built. Further we document these requirements in the form of SRS/FRS/Use Cases/Specification document. Moving to the next step we design the system on the basis of the requirement and we produce System Design Document(s). Based on the SDD, developers code the system. Once the system is build and released for testing , testers test the system against the documented requirements by executing test cases and adhering to a test plan. Once the system is ready for client release it enters into the last phase under which the system is implemented at the client site and then maintenance of the system can be done either by the same organization Or it can be outsourced to a different organization depending on the terms and condition in the initial contract.

Most important point to remember is that output of every phase in SDLC is a document. Even at the end of the last phase we prepare documents such as User Manuals and other related stuff. Now coming back to our main topic where does the testing process starts / fits in / comes into picture in the SDLC and the answer is just after the requirement phase. As soon as requirement phase is over and the SRS is freezes and is ready to use further then the activities progresses in two direction. One direction heads towards development and combines with next phase of SDLC. Another direction correlates to the fourth phase of SDLC , testing phase. Under this we first prepare the “Test Plan” . Test Plan is the bible of the whole testing activity to be carried out in the particular project. It contains various details but the most important which is / should be there in every test plan are –
- Brief description/introduction/overview of the system.
- Intended parties / reference documents
- Test items
- Features to be tested
- Features not to be tested
- Approach
- Item pass/fail criteria
- Suspension criteria and resumption requirements
- Test deliverables
- Testing tasks
- Environmental needs
- Responsibilities
- Staffing and training needs
- Schedule
- Risks and contingencies
- Approvals

Just a small note on who creates the test plan , it is the responsibility of senior member of testing team be it team lead/project lead. Once the test plan is freeze, testers are clear with the schedule, what is and how it is to be tested, approach to be followed and their individual responsibilities. Now the testing can proceed to the next step of designing test cases/scripts. Designing of test cases requires detailed knowledge of the system and thus test cases are designed on the basis of SRS/FRS/Requirement Specification. Best practice is to study the requirements , understands it and then come up with TEST SCENARIOS. A test scenarios is just a one line description of what are we testing. Now for testing this, you will perform some steps (Steps to be performed) which may / may not take some input data (Test Data) and has some result (Expected Result)

Thus, Test Case = Description + Steps + Test Data + Expected Result + Actual Result (Only at the time of execution) + some optional components like defect ID, severity, priority etc.. )

Once the test cases are created they are to reviewed by peers/BA’s/Senior members of the team. It’s a good practice to review the test cases as the creator of these test cases might miss some scenario, test cases may contain some language related mistakes. Further it’s good to have a TEST CASE CREATION CHECKLIST to reduce the review time. As per the recommended process review results should also be recorded in TEST CASE REVIEW RECORD (After all it helps in appraisals of testing team members J ). Once the test cases/scripts are freezes they are ready to execute on the build. When the developers releases the build for testing WE the testers execute the test cases and start fining the defects. Defects are then logged , fixed, resolved , closed and tracked carefully. In the test execution phase there are iteration cycles which depends on bug fixes, number of critical defects open/fixed. The decision to stop testing depends on many factors like –
- Testing budget of the project.
- Project deadline and test completion deadline.
- Critical test cases are successfully completed with no show stoppers OR even if some test cases fail does not have any show stoppers.
- Meeting the client requirements to certain point.
- Defect rates fall below certain specified level & High priority bugs are resolved.

Once the testing is over systems is released for customer usage.


END of POST , needless to say as always comments/suggestions are most welcome.

Basics of software Defects/Bugs

Basics of software Defects/Bugs -

In this post, I am sharing my understanding as to what a software bug is , what should be done when we find one and their overall lifecycle and related content.

A defect OR bug in a software systems is a state/scenario where a software system is functioning OR acting in a different manner from what has been specified in requirement. In simple words , it is deviation of software from the specified requirements. It is the state of software when it behaves in some unexpected manner. Software Testers main job is to find out these defects OR bugs in any software system. Now when a defect is found it has to be recorded carefully. Most of the organizations use some software tools for recording and tracking of these bugs and many of them use standard WORD /EXCEL formats to record these bugs. Whatever be the way most important part is that these bugs should be recorded however recording these bugs in software tool is much convenient as tracking is made easy by using these tools. There are many bug tracking software available in the market both freeware and license tools.

As soon as a tester finds then before logging / recording a bug the first part is to reproduce it again so as to get the reproducibility rate. In case it is an obvious deviation from the requirements then we should not waste time in reproducing it and it should be logged then and there. now once we are confirmed that there is a bug in current system next step is to log it in bug tracking tool / standard template used in organization. The reason why we log is so that we bring this in attention of the developer. Sometimes , higher management / client also wants detailed defects reports / number of bugs in the system etc..

Recording a bug requires some skills, there are some mandatory OR standard information given with every bug/defect. Regardless of what tool/template you use in your organization, every bug should have following information –

Short description – A shots and concise description of what the defect is , in which module it occurred.

Steps to reproduce – Detailed steps to reproduce the defect with test data. Test data is optional part, it the defect is there with some specific data set then it has to communicated.

Actual Results – what is exactly happening after performing the above mentioned steps.

Expected Results – what should happen as per the requirement specification.

Environment – details of the environment in the defect is occurring.

Severity – the impact of the defect on other parts of application.

Priority – how soon the defect has to be fixed.

Version – version of the application in which the defect occurred.

Assignee – Every defect is assigned to somebody so that this person can start working on / take any immediate action on the defect.

Apart from the above we can include some additional information like reproducibility rate and other environmental details. Thumb rule while writing a defect report is there should be enough information required to reproduce the defect at the developers end. Information must be to the point not much not less as both these situations are dangerous. Excess information confuses the developer and with less information developers will keep revolving around your chair J

Now a defect also has a lifecycle. When a tester finds a defects and logs it into the specified system it is in state NEW. From this the defect enters into OPEN state when the lead assigns it to any developer for working on it. As the developer starts working on it, the defect is in WORKING state and when the defect has been resolved by the developer then it enters into RESOLVED state. This is the state when it comes back to the tester for verifying. Now when the tester verifies it and found that it is fixed then the tester closes the defect and the state is CLOSED. If in case it is not fixed then tester reopens it with state REOPEN and again the normal cycle goes on till it get closed. This is very general bug life cycle with no variations. But I wish this could be the stats as it is J. From the state NEW a defect can move onto DEFERRED in case the development people feels that this defect can be ignored right now and can be fixed in later release. A defect with NEW state can also move on to NOT A DEFECT/ NOT REPRODICIBLE depending on what the current state of requirements OR information provided in the defect report. In both these cases, it again comes back to the tester and now tester has to close it OR provide more information to the developer and further reopen it.


That’s the end of the post and as always comments/suggestions are welcome for improvement. I would also like to discuss and correct my understanding (if wrong) through this post/blog.



Thanks & Regards,
Amit

Basics of Software testing- 1

Basics of Software testing –

What is “Software Testing” - There are many definitions available on the internet given by various scholars in this field and everybody’s definition is different. Ask this question to a 1 year experienced person he will give you a bookish answer and If you ask this question to a person having 4 OR more years of experience in this field he might not able to give you a perfect answer . I would like to define it in my terms which may be similar with any scholars definition. As per my experience Software testing is an activity/phase/process in SDLC where in we test whether the software is working as per the its requirement specification and in turn we measure the quality of the software developed. It is a process of executing a program or system with the intent of finding errors and evaluating it for conformance with the requirements specification.

Now on the basis of approach followed testing can be divided into –
- White Box
- Black Box

When we say that we are following/doing “White Box testing”, we mean that a testing activity in which we have access to the code of the system/module/ function we are testing and we are aware of the logic implemented in it. This knowledge may help us finding out the right place where the bug/defect has occurred and wrongly implemented logic.

Coming on to “Black Box testing”, In this type of testing we do not have access to the actual code of the system neither we have knowledge of the logic implemented. In this type of testing , tester is more concerned about the output which he/she gets from the system on the basis of the input given.

On the basis of types, there are four types of testing –
- Unit testing
- Functional testing
- Integration testing
- System testing

Unit testing is the primary testing activity carried out at the code level. It intend to find out the fault/bug in smallest unit of a project – A Program / Function. It follows “WHITE BOX” approach and is different from debugging in the sense that debugging is executing the program step by step to diagnose a problem where as Unit testing is broader activity which covers not only executing a program but also checking the placement of elements on the screen, performing nominal operations with them and related activities. For eg. If my program accepts input in a text field ‘T’ and it is not accepting that then debugging comes into picture. By executing the program step by step we will find out where the problem is. While in the same example Unit testing refers to testing whether the user is able to input the characters, fields are getting displayed at proper place and so on. Developers are responsible for UNIT TESTING.

Functional Testing is a step further to unit testing. This refers to testing functionality of the application/modules of the application as per the requirement specification. Test Engineers are responsible for it and they write test cases / scripts for performing functional testing.

Integration Testing is another steps further in testing of an application and it refers to testing the combined parts of the application , interaction of different parts of applications with each other. Under this different application parts (modules) are combined together and the application behavior, data flow between these parts, interaction between them is tested .

Systems Testing is the last testing activity conducted on any software system / application. It refers to testing the system as whole and confirm that whether it meets the requirements OR not. Apart from functional requirements systems testing also covers non functional requirements like performance, usability, security, reliability maintainability and other related factors.


As always, suggestions / comments welcome. Also I would like to have inputs on what more topics can be written


-Amit

Manual Testing V/S Automation Testing...

In recent days, I am following a discussion on a very popular professional website linkedin and the discussion is about “Which one is more crucial in testing? Manual testing or Automation testing?"

In my opinion, Manual testing is the most crucial and important as compared to automation. In the following content I am citing my reasons as to why I consider “Manual Testing” more important compared to “Automation testing”

Firstly, Manual testing is the initial level of testing carried out on every software product. Looking on to the stages of STLC (Software testing life cycle), Test Planning is a manual activity wherein we analyze the requirements/product and come up with a concrete approach of how & what we will test and who will test. Now after this we commence to “Test Design” phase where in we design high level test scenarios by analyzing the requirement document. This is again a manual activity and there is no alternate of it. On the basis of these scenarios we design detail test cases which we execute on the application. Its only after initial iterations we identify the test cases which we can automate. Generally, the first test cases to automate are the smoke/sanity level test cases which decides that build under test is testable further OR not. Once the build gets stable we automate more and test cases related to different modules of application. This decision to automate test cases further depends on how stable your application/different parts of application is.

Secondly not all testing activities can be automated. Testing related to usability of application/product cannot be automated as it is very subjective. Moreover, when we release the software for BETA usage and urge user to test it and provide their feedback then this is more of an manual activity rather than automation as most of end users does not have automation tools on their site.

Thirdly, automation testing is covers OR relates to specific activities OR types of testing which majorly includes Regression and load.

Moreover in my opinion automation testing is more successful in case of PRODUCT rather than projects (Customized solutions developed for specific process in an organization). The reason for this is a PRODUCT is more stable and running in market whereas in a project requirement changes often and it is tedious to maintain the automation scripts.

So at the end I would say that “Manual Testing” is more important as it is initial activity and has wider scope because only on the basis of this we can decide what to automate and when.

As always , This is an open discussion and suggestions / comments are most welcome.

The 10 rules of e-mail etiquette

In this blog ,I am sharing some tips published on a very popular Indian website (www.rediff.com) for writing effective emails. The idea of posting this came to my mind due to a recent incident happened. One of my close friend asked to me to send some resumes for an off-campus drive in their company. I asked some of my friends for the referrals and then one person told me that his cousin is looking for job . I told him to forward CV to my friend’s mentioning as “Referred by Amit Jain”. To my surprise that’s person forwarded his CV and content of email consist of “Reference by amit jain” as it is, nothing more nothing less. I wondered that’s a Engineering degree holder does not know how to email. His email does not contain any salutation , greeting , subject line… nothing just plain sentence “Reference by amit jain” and that too grammatically wrong (Any name should start with capital and not as “amit”). So after this I thought of sharing a very useful post which was posted on rediff. Her you go –

The 10 rules of e-mail etiquette
Rule 1: Do not skip the head or tail of the e-mail
Salutation, body and sign-off are three principal parts of the e-mail message. Be absolutely sure not to miss any of them unless you are writing to a college friend in a casual setting.

Rule 2: Use simple and direct salutation; the same for sign-off
Dear Dilip, Hi Dilip, Dear Mr Kumar are proper professional salutations.
Do not get carried away while showing respect and do not borrow from letter-writing assignments you did in class VIII. "Respected Sir" is way too deferential and so is "Honorable Mr Kumar". While signing off too, keep things simple.

Rule 3: Use smart subject lines
Ideally, the purpose of your message should be clear in the subject line itself. Use as much information in the subject line as possible. Leaving out the subject field is highly unprofessional and so is using something meaningless like 'Hello', etc.

"Resume for s/w engineer adveritsed in TOI dated "

Rule 4: Avoid 'bureaucratic' sentences
Professional or business English is different from the bureaucratic English typically used in government offices. Using unnecessary long-winded sentences just makes the message difficult to understand.

Rule 5: Use as few words as necessary
Long e-mails take longer to read and tell the reader you are not a very efficient writer. Any word or group of words which can be shortened should be shortened. Professional communication should be sharp, unnecessary words have the potential of confusing the reader. Brevity is the soul of wit. It indeed is the soul of good professional writing.

Rule 6: Answer e-mails the same day
Delay in responding to e-mails gives out an impression of carelessness and unprofessionalism and also, that responding to that particular person is not high on your priority list. A very useful rule of thumb is to read the e-mails the same working day and any e-mail that you receive during the day should be replied to before the end of the working day, even if it means sending back a short note saying that you will get back to him/her soon with a detailed response.

Rule 7: Be careful with attachments
In these days of spam and Trojans and viruses, attachments are risky business. Try to have a 'no attachment' policy unless the person is expecting one or an attachment needs to be sent. Need is the key, if an attachment is not required, skip it. Several spam filters summarily send the mails with attachments to junk and that's another reason to use attachments sparingly.

Rule 8: Avoid using excessive capitals
Capitalization of unnecessary words amounts to shouting in the cyber world. Use capital letters only to begin sentences and for names -- exactly as they taught you in school grammar. Using capitalization to stress or emphasize a point is often considered rude and aggressive.

Rule 9: Be careful with 'reply all' and forwards
If the message does not need to be read by all in the mailing list, do not 'reply all'. These days everyone receives so much junk mail that adding an extra irrelevant email to them reduces your credibility and is bad manners. Similarly, do not forward chain letters or hoaxes or, 'Send it to 25 people within 15 minutes else your cat will die' email.

Rule 10: Avoid SMS language
SMS language is only for SMSes. Use proper English sentences and words while writing emails.
"Gr8 2 hear frm u" may be a nice way to greet a friend on SMS or orkut/facebook, but it can kill the professionalism of your e-mail. Avoid it.


If clothes make a man, then e-mails make a professional. Use it smartly as a tool to create a powerful professional impact.

Major points while testing a Mobile Application

Article content: Major points while testing a Mobile Application
This is my first blog post and I am sharing some basic points to be considered while testing a mobile application (Currently, I am working on it) are –

• Navigation of the application - We need to verify the whole navigation of the application and need to find out the dead ends . Traverse whole application, every possible path and come back to the starting point. In this way we can find out the dead ends, inconsistency in the navigation and lot other things.

• GUI of the application – Most of the mobile applications are developed for one platform / screen resolution and ported on other platform (Platform Porting) OR on devices with different resolution (Device Porting). In this process , there are many GUI issues which gets introduced in the application. These issues should be reported and addressed carefully.

• Behavior of the application on Call/SMS (Suspend/Resume) especially on entry screen & popup screen – This is one of most important activity while testing a mobile application be it a game / application residing on device OR application using communication protocols. Mobile applications using internet / client server communication needs to be tested for this scenario on the screens / process establishing network connections.

• Behavior of the application on pressing CLEAR key & END key – This is also one of the most important testing activity while testing a mobile application. When implemented default, CLEAR key takes the user back to the previous screen and END key ends the application. It needs to be tested carefully as there are chances of application crash. In my experience, I found one interesting bug for developers with CLEAR key. There was one data entry screen with default letter displayed in the text box. Now when the user taps on the text box and presses CLEAR key to clear the data, type in special characters in the text box the application was crashing.

• Behavior of application when memory is almost full (MaxFileCount) – This test is important when your application is creating any file(s) on the user device. Many times developer does not handles this situation well and the application crashes by giving a unfriendly error message (Exception found.. )

• Behavior of the application on application directed SMS (Syntax is “//brew::”) – This test is one of the most important in BREW applications. By this we test the behavior of application by sending the message to invoke the same application while it is running in foreground.

• In BREW applications apart from functional tested cases prepared we also need to execute standard set of test cases provided by the NSTL.

• Sound functionality of the application (if applicable)

• Timer functionality (specially on Suspend/Resume)