Official Honeymoon Period (OHP)
In my total 6+ years of work experience in Software Industry, I have seen n number of people who are not keen to work when they issue notice to the company about their parting from company. Notice period will become the “Official Honeymoon Period (OHP)” for them. Following actions have been noticed by me when any of the employees is enjoying his/her OHP.
1. Late coming and early going
2. No work responsibility
3. Least interaction with the seniors
4. Internet browsing and chatting
5. Searching for the better job (they already have a job in hand)
6. Using official phone
7. Consuming all the remaining leaves
8. Not interested in knowledge transfer process
9. Study about the next company and their work processes
10. Performing all the other remaining unofficial activities (if I missed anything)
Basically, they are interested in only getting a better job and their last salary. In my opinion, the salaries should not be given to those employees who are performing these kinds of rubbish things. Company relieving letter should be given to the employee only when the HR gets a “Green and Clean” signal from the management. Management should try their best to assign work to them and notice them on a fast pace. At least, management should try to perform the knowledge transfer sessions from them. If the management is not happy with the way of their actions after giving the notice, they should at least inform HR about this and HR must take some indiscipline actions against them.
On the other side, I have seen a few employees who act more responsible in this period. I have seen two guys till date in my carrier who acts like anything in their notice period. They tried their best to give the company whatever they can in that period. I really appreciate those guys.
The whole story can be summarized in one line that there should be no notice period. Ha ha … Just kidding.
We should notice the notice period guys in a proper way and precede their proceedings accordingly.
-- Sanat Sharma
Friday, October 26, 2007
Wednesday, October 24, 2007
The habit of finding Bugs (continue)..
In continuation of my blog (headline above) that I have published on September 2007, I was not sure whether the mentioned habit is good or bad. But few days back, one of my friends said that he is also doing the same task in his personal life. There was an issue in his telephone bill that he got from the company. He discussed them with those guys and they corrected their mistake. Similarly, he was saying that he is now trying his best to get the full perfection in his life at least from personal side.
Although he has only one plus year of experience in testing domain but I think he is doing the right thing. Or directly he is supporting me. According to his statement, he is now able to get the things done at right time in right place with right attitude. I think this is one of the most important aspects of anyone’s life. Being a tester, you should be able to find the issues in your personal life. But finding the issues is not sufficient. You should be able to resolve them amicably and give your best not to repeat that issue.
The above views are totally coming from my mentally. This doesn’t mean that each and every tester should try to follow these things. In my opinion, this kind of attitude makes you a person who is more aligned towards the complete perfection. You should be good tester in your professional life and try to become the same in your personal life also. I know by having this kind of attitude, people will try to put you on the spot. But you should be careful for this and handle the situation in a matured way.
But this will take time. It takes courage to grow up and become who you really are. Remember Rome was not built in a day.
So, all the best and happy bug finding. Both in Professional and Personal life.
-- Sanat Sharma
In continuation of my blog (headline above) that I have published on September 2007, I was not sure whether the mentioned habit is good or bad. But few days back, one of my friends said that he is also doing the same task in his personal life. There was an issue in his telephone bill that he got from the company. He discussed them with those guys and they corrected their mistake. Similarly, he was saying that he is now trying his best to get the full perfection in his life at least from personal side.
Although he has only one plus year of experience in testing domain but I think he is doing the right thing. Or directly he is supporting me. According to his statement, he is now able to get the things done at right time in right place with right attitude. I think this is one of the most important aspects of anyone’s life. Being a tester, you should be able to find the issues in your personal life. But finding the issues is not sufficient. You should be able to resolve them amicably and give your best not to repeat that issue.
The above views are totally coming from my mentally. This doesn’t mean that each and every tester should try to follow these things. In my opinion, this kind of attitude makes you a person who is more aligned towards the complete perfection. You should be good tester in your professional life and try to become the same in your personal life also. I know by having this kind of attitude, people will try to put you on the spot. But you should be careful for this and handle the situation in a matured way.
But this will take time. It takes courage to grow up and become who you really are. Remember Rome was not built in a day.
So, all the best and happy bug finding. Both in Professional and Personal life.
-- Sanat Sharma
Thursday, October 11, 2007
Software Entry-Exit criteria
There are lots of discussions about the Entry-Exit criteria within the management for a software release. Here I am summarizing few points that I think should be a solution for most of those dialogues.
Entry criteria –
Entry criteria means when the release should be accepted for testing. Now there are three filters for entry criteria:
1. The first Entry criteria should be from the Configuration Management team. They should accept the release only if the release was being thoroughly unit tested by the development team.
2. The second Entry criteria should be from the Test team. They should accept the release only when the release was being thoroughly sanity tested by the Configuration Management team.
3. The third Entry criteria should be within the Test team. They should perform the acceptance testing and if passed, they should start performing the major testing for the release.
If any of these entry criteria failed, the release should not be accepted by any of the team and return back to the development team.
Exit criteria –
Exit criteria means when the release should be green signaled or red signaled by the test team. The exit criteria can be of three categories:
1. The first exit criteria are in case when any of the above entry criteria failed.
2. The second exit criteria are in case when the test team has found some major or critical bugs in the system while performing the major testing effort. The number of bugs that will decide the fate of the release should be discussed and mentioned in the test plan.
3. The third exit criteria is when complete testing has been done, bugs has been logged and test report has been sent to the development manager.
If the release fails due to any of the two reasons mentioned in the Exit criteria, a revision kit should be delivered by the development team. And if the release has gone through the third point mentioned in the Exit criteria, a correction kit should be delivered to the test team.
-- Sanat Sharma
There are lots of discussions about the Entry-Exit criteria within the management for a software release. Here I am summarizing few points that I think should be a solution for most of those dialogues.
Entry criteria –
Entry criteria means when the release should be accepted for testing. Now there are three filters for entry criteria:
1. The first Entry criteria should be from the Configuration Management team. They should accept the release only if the release was being thoroughly unit tested by the development team.
2. The second Entry criteria should be from the Test team. They should accept the release only when the release was being thoroughly sanity tested by the Configuration Management team.
3. The third Entry criteria should be within the Test team. They should perform the acceptance testing and if passed, they should start performing the major testing for the release.
If any of these entry criteria failed, the release should not be accepted by any of the team and return back to the development team.
Exit criteria –
Exit criteria means when the release should be green signaled or red signaled by the test team. The exit criteria can be of three categories:
1. The first exit criteria are in case when any of the above entry criteria failed.
2. The second exit criteria are in case when the test team has found some major or critical bugs in the system while performing the major testing effort. The number of bugs that will decide the fate of the release should be discussed and mentioned in the test plan.
3. The third exit criteria is when complete testing has been done, bugs has been logged and test report has been sent to the development manager.
If the release fails due to any of the two reasons mentioned in the Exit criteria, a revision kit should be delivered by the development team. And if the release has gone through the third point mentioned in the Exit criteria, a correction kit should be delivered to the test team.
-- Sanat Sharma
Monday, October 08, 2007
Requirements or Bug Database:
Requirements play a major role in developing software under a normal circumstance. Collecting Business, User and Functional requirements is the first activity that should be performed in the initial stage of the software development life cycle. Sometimes, the system engineer (or requirement collector) could not able to collect the complete requirements and due to which nothing can be planned in a proper way. The development team starts coding without having a complete knowledge of the design and consecutively test team have no proper documents to test the release.
In this type of scenario, most of the bugs found by the test team converted into the limitations and remaining bugs are being logged in the Bug tracking system. That is the reason I am saying that our bug database should not be our requirement document.
The point that one should ask from the development is that whatever mentioned in the release notes has been implemented in the release or whatever implemented in the release has been mentioned in the release notes. We should be very careful while answering this question as selecting any of the option against this question will definitely tell everyone what methodology you are following in your software life cycle. Is it a software engineering or a reverse software engineering?
-- Sanat Sharma
Requirements play a major role in developing software under a normal circumstance. Collecting Business, User and Functional requirements is the first activity that should be performed in the initial stage of the software development life cycle. Sometimes, the system engineer (or requirement collector) could not able to collect the complete requirements and due to which nothing can be planned in a proper way. The development team starts coding without having a complete knowledge of the design and consecutively test team have no proper documents to test the release.
In this type of scenario, most of the bugs found by the test team converted into the limitations and remaining bugs are being logged in the Bug tracking system. That is the reason I am saying that our bug database should not be our requirement document.
The point that one should ask from the development is that whatever mentioned in the release notes has been implemented in the release or whatever implemented in the release has been mentioned in the release notes. We should be very careful while answering this question as selecting any of the option against this question will definitely tell everyone what methodology you are following in your software life cycle. Is it a software engineering or a reverse software engineering?
-- Sanat Sharma
Subscribe to:
Comments (Atom)