Three days of Experience

Talking about my experience, last week I was shifted to a team of developers who are assumed to be the best in our organization (coz they were highly paid and yeah they worked smartly as in code, logics, communicating and in many ways).

DAY 1

It took me one whole day to go through the requirements of the developed software, mean while team member around me started chatting with me asking about me, my experience, why testing (many more questions) and unintentionally they were even trying to nag out me (they were pretending to be happy as a tester joined their team but, their intention was to remove me out of this team) because no one like testers or can I say no one like spectators on them.

After few hours, truly speaking I felt, will I be able to find error, bugs, mistakes, defect in their work, coz their talks created a perception in my mind due to which my approach, my mentality changed towards finding bugs. I was not supposed to run the software on the same day but, I did, to feel the complexity of the developers and software.

As I said earlier due to my brain wash and change in perception I couldn’t find any error, bugs.
Now, I was totally bugged out. I left application and went back on requirement document.

I know that testers always cannot find bugs but, in my case I was feeling horrified, not exactly but, yeah anger was there in me (I couldn’t find bugs. Huh!). There were only two questions running in my mind.
1. Are they so good in developing?
2. What if I don’t find any error, mistake, bug…?
On this note I left for the day (back to home).

DAY 2

I’ll describe my day two in point format.
1. Revised a small part of requirement you can say phrase 1.

2. Took a U-turn on software and simultaneously went through requirement doc. and application.

3. Slowly slowly started understanding the purpose of the software and started using the software as per the requirement and from the N number of user’s point of view. (I know I can’t think like users coz every one is different but, tried my best to view, throw my perception in different angel, mode of situation, permutation combination)

4. Unbelievingly my half day went like hopping here and there. Finally, after lunch I was ready with all requirements standing firm in my mind, all my thoughts very clear. Started my testing.

5. Took up a small module, within five minute two typo errors. WOW. (small but, good for that point of time)

6. Within 20 minutes two functionality errors (which was missing as per specs.). Yahoo!! (that time I was feeling great)

7. Now comes the coding of the module, as per my knowledge I was a management student without any technical knowledge. Then two was curious to know more about this team’s coding.

8. Started with date format changed the date format viewed the application, this Exception error was not handled. (This date was exported from another application by running the windows services.)

9. I was feeling extremely happy not just because I was finding error but, by thinking that yes now I can also add value to product. This feeling was amazing.

10. Talking about coding errors, this application screen was in a grid format in which you can add different fields as per your needs and mails had to be send from this application if some one passes a comment on you, this was not happening just because, the added field was suppose to be added in the end but, I added it at the top of all the field due to which the mail id of the user on which the mail had to be sent was disturbed and the code was written using an array now, ERROR. Excellent. BRAVO.

11. Day end but, before leaving office I was supposed to report my PM. (I had reported this error on a bug tracking tool called project management)

12. As soon as I entered his cabin he was smiling, the first sentence he spoke was, “So, I got some one to bug me and this team”. I was appreciated by him.

DAY 3

The whole team came to know about the error reported, all my well wishers were happy for me, including the expert team members. :-))

**NOTE** The errors reported by me were nothing great but, well it does matter to a fresh unidentified tester.

Traveling Bombay to Bangalore...

This post is truly dedicated to all the new members I met, while traveling to Bangalore.
Firstly, I would like to thanks Raghu Sahay from Pune for joining me in my journey, and without him this event of Bangalore would have been a difficult task for me. And thanks to testing which added new friends in my life.

Getting back into flashback, my journey began at 11.00am from Bombay, I had to catch a train from Pune (to Bangalore) so caught a bus to pune. While traveling in bus, (to pune)
I was accompanied by a sweet woman, woman because I thought she was married but after some chat I discovered that she is yet a girl (unmarried) now you must be thinking what made me believe that she is married woman actually, that girl had a great perception about our Indian culture which usual girl wouldn’t talk about, difference between different mindset all this topic prior to my discover made me believe that she is married, which was very wrong. You know guys what I appreciate the most about that girl, she is working even though her dad is at one of the precious post in government. Keeping that in mind and supporting her own self esteem, she’s working Great isn’t it ?

Now, I am feeling proud to be an Indian because mindsets are changing.
We shared lots of information, thoughts and views. Thanks to that girl else my journey would have been a great bore for me.

I met raghu who was waiting at the Pune station. Unfortunately, are tickets were not confirmed and we were hopeless coz while booking our tickets we got a waiting nos. 100 but, at that point of time are current status was 3 you cannot imagine how bad that nos. 3 was for us. We felt so bad, we left behind by just 3 seats.

For few minutes we thought lets get back to our respective homes. But then, raghu approached me and said do you like adventure, I: Yes. Raghu: so let go adventure is waiting for us and pointed towards the train filled with people (summer vacations).
You know guys we even tried the mode of corruption towards TTE to pull out at least one seat but, traveling without seats was our destiny. So, NO seats yaks.
From that point we began our search, search for little space, some extra space where in we both can place are head. Believe me, I was horrified because journey of 18 hours and no confirm seats (this was my first time).

After a long discussion finally our journey began and some how we managed to settle down. After few minutes our good time started, start to end of the journey we traveled, with all the royalties what a prince has, kind words and the way we act or responded to people around us brought this change. You know guys what was the funniest part, we both were sleeping half way on some others seat without any argument (really great adventure). Some one has said it very truly “humans are always hungry to listen kind words”

Finally, we reached Bangalore. We decided to stay at Raghu’s friend’s house where in I met his 4 friends, these 4 guys were damn fantastic personalities I felt like meeting my friends after a long time.
Let me have the pleasure to introduce you these 4 guys.

1. Yogesh (puppy) 2. Vikas 3. Sid (piddi) 4. Cirag.

I found puppy and vikas as entertainer, I mean you’ll never feel bored if you are around these two. Talking about sid and cirag these two are the observer, they’ll always analysis you first what category you belong if you matched their mentality then boom lets have fun. You can say they had a supporting spirit, supporting each other. I have met many friend groups, friend circle many, but this was my best experience in my life and I wouldn’t forget these four friends in my life. Seriously, what a supporting spirit, hats off friends. Friends you’ll really rock together.

You might have seen friends fighting and breaking their friendship, these guys also fight but, the next morning its like yesterday was a night mare or a bad part or a hurdle which we have crossed successfully shake hands and move ahead, Great yaar, what an attitude.
I enjoyed a lot because it was like a dream because few guys don’t get a chance to live like this, I mean with friends and all. I am one of those unlucky guys.

Days went like cool breeze and we headed back to our home town.

OOPpss !! I forgot to tell you the main purpose of going to Bangalore. I was supposed to attend BWST-1 conference. A conference all about software testing, my next post will be on that and what I learnt from others presentation.

According to IEEE the basic procedure(steps) to be followed while conducting ' Testing '.

IEEE 829 Documentation
Over the years a number of types of document have been invented to allow for the control of testing. They apply to software testing of all kinds from component testing through to release testing. Every organisation develops these documents themselves and gives them different names, and in some cases confuses their purpose. To provide a common set of standardised documents the IEEE developed the 829 Standard for Software Test Documentation for any type of software testing, including User Acceptance Testing. This White Paper outlines each of the types of document in this standard and describes how they work together.

The Types of Document
There are eight document types in the IEEE 829 standard, which can be used in three distinct phases of software testing:
1. Preparation Of Tests
Test Plan: Plan how the testing will proceed.
Test Design Specification: Decide what needs to be tested.
Test Case Specification: Create the tests to be run.
Test Procedure: Describe how the tests are run.
Test Item Transmittal Report: Specify the items released for testing.
2. Running The Tests
Test Log: Record the details of tests in time order.
Test Incident Report: Record details of events that need to be investigated.
3. Completion of Testing
Test Summary Report: Summarise and evaluate tests.
Documentation For Preparation Of Tests
The preparation for testing is the most important part of any software testing project and easily accounts for most of the paper work. The purpose this stage is to prepare an effective and efficient set of tests, and create the environment for them to run in.

IEEE 829 - Test Plan
The Test Plan is the pivotal document around which all the software testing projects revolve. It describes:
what has to be done,
to what quality standard,
with what resource,
to what time scale,
and outlines the risks and how they would be overcome.

IEEE 829 - Test Design Specification
Creating the test design is the first stage in developing the tests for a software testing project. It records what needs to be tested, and is derived from the documents that come into the testing stage, such as requirements and designs. It records which features of a test item are to be tested, and how a successful test of these features would be recognized. As an example lets use a Billing project from which the following testing requirements may be defined:
A normal bill can be produced.
A final bill can be produced.
The volume discount is properly calculated.
The test design does not record the values to be entered for a test, but describes the requirements for defining those values. This document is very valuable, but is often missing on many projects. The reason is that people start writing test cases before they have decided what they are going to test.

IEEE 829 - Test Case Specification
The test cases are produced when the test design is completed. Test cases specify for each testing requirement:
The exact input values that will be input and the values of any standing data that is required,
The exact output values and changes of value of the internal system state that are expected,
And any special steps for setting up the tests.
Defining the expected values is very important, for only by doing this can discrepancies be spotted. However in some projects they are not defined which results in a very poor quality set of test cases. A feature from the Test Design may be tested in more than one Test Case, and a Test Case may test more than one feature. The aim is for a set of test cases to test each feature from the Test Design at least once. Taking the Billing project example all three requirements could be tested using two test cases:
The first test case could test both that a normal bill is produced and that a volume discount is properly calculated.
A second test case could check that a final bill is produced and a volume discount is calculated.

IEEE 829 - Test Procedure Specification
The Test Procedures are developed from both the Test Design and the Test Case Specification. The document describes how the tester will physically run the test, the physical set-up required, and the procedure steps that need to be followed. The standard defines ten procedure steps that may be applied when running a test.

IEEE 829 - Test Item Transmittal Report
This curiously named document is not derived from the Test Plan but is the handover document from the previous stage of development. In User Acceptance Testing this may be the completion of System Testing. It describes the items being delivered for testing, where to find them, what is new about them, and gives approval for their release. The importance of the document is to provide to the testers a warranty that the items are fit to be tested and gives a clear mandate to start testing. Do not start testing without receiving one!
Documentation For Running The Tests
When the tests have been developed then they can be run. The schedule of what Test Cases are run and when, is defined in the Test Plan. The test results are recorded in the Test Log, and in Test Incident Reports.

IEEE 829 - Test Log
The Test Log records the details of what Test Cases have been run, the order of their running, and the results of the test. The results are either the test passed, meaning that the actual and expected results were identical, or it failed and that there was a discrepancy. If there is a discrepancy than one or more Test Incident Reports are raised or updated, and their identities recorded on the Test Log. The Test Log is important as it allows progress of the testing to be checked, as well as providing valuable information for finding out what caused an incident. If an incident is a coding fault, the fault may have occurred not in the Test Case that failed but in one that was run previously. Thus the sequence of the tests enables the fault to be found.

IEEE 829 -Test Incident Report
This document is deliberately named as an incident report, and not a fault report. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other than a fault in the system. These include the expected results being wrong, the test being run wrongly, or inconsistency in the requirements meaning that more than one interpretation could be made. The report consists of all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution. The report will also include, if possible, an assessment of the impact upon testing of an incident. The relationship between the Test Log and the Test Incident Report is not one to one. A failed test may raise more than one incident, and at the same time an incident may occur in more than one test failure. Taking the Billing project example, if both test cases completely failed than three Test Incident Reports would be raised:
The first would be for failure to produce a normal bill,
The second would be for failure to produce a final bill,
The third for failure to calculate the volume discount for both the normal and the final bill.
It is important to separate incidents by the features being tested so as to get a good idea of the quality of the system, and allow progress in fixing faults to be checked. A useful derivative document from the Test Incident Report is a Test Incident Log to summarise the incidents and the status. This is not an IEEE 829 document as all it values can be derived from the Test Incident Reports.
Documentation For Completion of Testing
Eventually testing will be completed according the criteria specified in the Test Plan. This is when the success or failure of the system is decided based on the results. The Test Summary records this information.

IEEE 829 - Test Summary
The Test Summary brings together all pertinent information about the testing, including an assessment about how well the testing has been done, the number of incidents raised and outstanding, and crucially an assessment about the quality of the system. Also recorded for use in future project planning is details of what was done, and how long it took. This document is important in deciding whether the quality of the system is good enough to allow it to proceed to another stage.

Use of the Standard
The standard is generic to cover all types of testing. As a result it allows the documents to be tailored to each situation. This means using the basic structure as given, but other documents can be added to it, sections can be added to each document, and further descriptions can be written. In addition some content can be referenced in another document. By using the standard means that anybody joining a project will know what documents are being used, and for what purpose, allowing them to become productive faster.