Eighty percent of all submitted résumés (and 100 percent of résumés sent to Fortune 1000 companies) get scanned by software commonly known as an applicant-tracking system (ATS), and such scanned résumés are stored on a server in a digitized format. Humans are seeing your résumé only if it resurfaces based on a query. That’s why most job applicants don’t receive responses from companies after submitting résumés. Therefore, in order to increase your résumé’s chances of being at least viewed by a human--even if it’s not thereafter considered suitable--you have to understand the process and beat them at their own game.
Human resources departments that use ATSs base their queries on keywords they lift from job descriptions or receive verbally from hiring managers. Based on that information, the ATS extracts appropriate résumés from the ones on file. The human resources employee’s query may result in just a few résumés or a vast number. The ATS also scores those résumés and sorts and prioritizes them. Then the employee reviews, say, 20 and submits 5 to be interviewed.
Your job is to ensure that you embed sufficient keywords in your résumé. So, what’s the best way to find those magical keywords? It’s a simple, albeit somewhat tedious, exercise.
1. Search the Internet via job boards such as Monster and The Ladders.com to find 5 to 20 job descriptions of jobs advertised in the field you’re interested in.
2. Cut and paste all of the descriptions one after another into a new Word document.
3. Review the document, resetting in boldface what you consider the keywords throughout.
4. Delete everything except the boldface words.
5. Alphabetize the words, and delete duplicates.
6. Copy your résumé into a new Word document, and repeat steps 3, 4, and 5 on that copy.
The two resulting lists will display which keywords from the descriptions are missing from your résumé. And now comes the creative part: you incorporate the missing keywords into your résumé so it seems seamless and a perfect match for the context in which the words are mentioned in the job descriptions.
By doing this admittedly laborious task, you increase manyfold your chances of being picked out from the crowd.
The article is taken from:
http://internsover40.blogspot.com/2010/06/is-your-resume-getting-thrown-in-trash.html
Friday, July 1, 2011
Thursday, August 12, 2010
Defect Triage
The term "Triage" comes from the French verb trier, meaning to separate, sort, sift or select. Triage" is a medical term describing the process of determining the priority of patient’s treatment based on the severity of their condition. It refers to dividing wounded or sick people into three categories: those who will die no matter what you do, those who will recover even if unaided, and those who will recover only if aided. In a situation where there's too much to do, you must concentrate on the third group (Ex: Watch Pearl Harbor scene, showing situation in hospital after Japanese have bombed the harbor).
This term has been introduced to software quality assurance to describe the function of assigning a priority and severity to new defects, usually by addressing several new defects at once every few days or as necessary.
If your project is very small, or isolated from other business units, triage may not be very useful at all. Similar to an emergency room that receives one patient per hour. This is usually not the case with large business.
Triage in software development requires three parties be present. Project manager, development lead, and test lead must be present at this discussion. Test lead facilitates a bug triage with a bug tracking system. Test lead reads the description of the bug to everyone, product generally asks some clarifying questions, and testing and development go back and forth discussion the importance and impact of their point of view. All three parties come to agreement and understanding on the severity and priority, or “actionable priority”, of the bug or defect, and the defect is marked as Triaged. Consistent triage meetings are important to ensuring a clear product backlog and reducing the need for meetings to talk about priorities.
Triaging a bug involves making sure the bug has enough information for the developers and makes sense, bug is filed in the correct place, bug has sensible "Severity" and "Priority" fields.
This term has been introduced to software quality assurance to describe the function of assigning a priority and severity to new defects, usually by addressing several new defects at once every few days or as necessary.
If your project is very small, or isolated from other business units, triage may not be very useful at all. Similar to an emergency room that receives one patient per hour. This is usually not the case with large business.
Triage in software development requires three parties be present. Project manager, development lead, and test lead must be present at this discussion. Test lead facilitates a bug triage with a bug tracking system. Test lead reads the description of the bug to everyone, product generally asks some clarifying questions, and testing and development go back and forth discussion the importance and impact of their point of view. All three parties come to agreement and understanding on the severity and priority, or “actionable priority”, of the bug or defect, and the defect is marked as Triaged. Consistent triage meetings are important to ensuring a clear product backlog and reducing the need for meetings to talk about priorities.
Triaging a bug involves making sure the bug has enough information for the developers and makes sense, bug is filed in the correct place, bug has sensible "Severity" and "Priority" fields.
Wednesday, August 4, 2010
Test to Break Attitude - Poor Concept
If you ask question that what makes a good software tester then most people reply that a good tester should have "Test to Break Attitude". Ex: “softwareqatest” website has mentioned "Test to Break Attitude" as first quality that software test engineer should have.
My point of view is different. For me, it is not the responsibility of software tester to break anything and neither does he break. It is the software developer that has left broken things for software testers to find it. If a tester finds a bug then it does not mean that he has broken anything, it was already broken. A tester just find outs the points and areas which are already broken and then digs deep in it.
Detecting a breakage is not a job all done for a tester? It’s a job half done and maybe it’s just the beginning. Further responsibilities of tester are the find out the conditions under which this break occur and under which does it not occur? And to figure out the exact and simple steps to reproduce this break, which are supported by images, presentations or clips etc. All this will help developers and other stake holders to reproduce the break at their end. Other questions that tester have to find out are: Scope: all areas effected by the break; after finding this break do we need to re-execute some of other test cases or what test cases to re-execute after getting the fix for break; what risks will arise due to break; was it possible to detect this break earlier, if yes then what factors avoided its earlier detection; should the testing process or strategy be modified to detect breaks earlier?
As a software tester, your job may include planning, conducting, and analyzing results in controlled conditions, which are designed to find any kind of breakages.
However, if you like to break then you may try to take up any demolition job.
My point of view is different. For me, it is not the responsibility of software tester to break anything and neither does he break. It is the software developer that has left broken things for software testers to find it. If a tester finds a bug then it does not mean that he has broken anything, it was already broken. A tester just find outs the points and areas which are already broken and then digs deep in it.
Detecting a breakage is not a job all done for a tester? It’s a job half done and maybe it’s just the beginning. Further responsibilities of tester are the find out the conditions under which this break occur and under which does it not occur? And to figure out the exact and simple steps to reproduce this break, which are supported by images, presentations or clips etc. All this will help developers and other stake holders to reproduce the break at their end. Other questions that tester have to find out are: Scope: all areas effected by the break; after finding this break do we need to re-execute some of other test cases or what test cases to re-execute after getting the fix for break; what risks will arise due to break; was it possible to detect this break earlier, if yes then what factors avoided its earlier detection; should the testing process or strategy be modified to detect breaks earlier?
As a software tester, your job may include planning, conducting, and analyzing results in controlled conditions, which are designed to find any kind of breakages.
However, if you like to break then you may try to take up any demolition job.
Subscribe to:
Posts (Atom)