Simple Guide To Write Software Testing Resume – Effective Resume Writing Tips

Are you ready to write a software testing resume? What all things you need to put into a CV to make it a real display of your skills? Don’t know? Read on to learn the same.

A Resume is the first step when you start searching for a job. It plays vital role for you to get an interview call or not. So the resume should be the one which showcase your skills correctly and present you as the apt person in front of the interviewer.

Resume writing is an art; it should showcase your real skills and should contain correct information. Some people copy sample resumes but forget to change the hobbies and details. Seeing a sample resume is not harm but your resume should be compiled with your details and skillset otherwise you will not be able to showcase your talent.

For a beginner, keep it simple and first start write down all your skills, tools you know, achievements, technologies, projects etc. then start molding it into a template.

First Page is the most important page of your resume. This page should contain crisp and clear details about your skill set and your objective. The employer usually takes only 30-40 sec to scan your resume and based on that your CV is either selected or rejected. Make sure your goal/objective are clear. When you are writing resume for a particular post, take care of few points in the resume

1. Make sure you read the job description carefully and then rate yourself in those skill sets and then highlight those skills first.
2. Keep the career objective up to the mark and avoid writing stories in the resume.
3. Write your on-job accomplishments/achievements on the very first page itself.

If you are a new comer then highlight your area of interest and your projects done within the college time. If you don’t have any software testing background and you want to get into the testing job then start doing dummy /online projects or can try some certifications like ISTQB etc. and those skills can be added in the resume on the very first page.

Nowadays we face high competition in automation/ agile testing. Take some certifications on testing/automation, agile and mention it into your resume, this would be of great help. So always keep learning and accessible yourself with new skills/tools.

 

Sections to be covered under your resume:

1. Personal Details – This contains your personal details which you want to share with the employer like name, email address and phone number. This should be on the top.
2. Career Objective – The objective should just one or two liner and should be clear and crisp.
3. Experience/ Professional Summary – The summary should be the short trip or snapshot to your resume. It should contain all the previous company and your roles.
4. Technical Skills – Technical skills is the most important section in your resume. Employer decision will depend on this. So make sure when you are writing for any job description, this should contain all the skills and tools which you know.
5. Testing Skills – Specific to testing, here you should write in which are of testing you have worked upon. For e.g. Requirement analysis, test planning, raising defects, bug tracking, reporting etc.
6. Management Skills (If any) – If you are applying for some lead position or above then this is the crucial section of your resume.
7. Domain Expertise – This part would tell your expertise in the domains such as banking, insurance, finance etc.
8. Projects Done – Mention all your projects accomplished and the awards you achieved in this. Under this section it has four points which should be mentioned
   • Client: Which client you worked for?
   • Location: where you were located?
   • Team Size: number of people you handled or worked with?
   • Duration: what was the duration of the project?
9. Education Details – It contains your education details .Remember the details should be in reverse order i.e. from highest to lowest.
10. References (if any) – Write down if you have any professional references. (This is for experienced ones only).

What points to be considered to make your software testing resume effective?

1. First and foremost, try to keep your resume short, crisp with maximum information. You are not writing a story. Use bullet points wherever required.
2. Use standard formats for resume – MS word or pdf with a 10/11 as font size.
3. Include maximum number of keywords related to software testing skills, these days resumes are picked using search engines.
4. Check for grammatical and spelling mistakes. A single spelling mistake would give a wrong impression.
5. Focus to write more on technical skills, Take trainings/ certifications to improve on your technical skills.
6. Showcase your problem solving skills and give an example for the same.
7. Include project details and on job achievements for the same.
8. For software testing, you should know at least one defect management tool and test management tool. Learn at least one tool for each, in case you don’t know any and add it to your CV. Some of the tools are like Bugzilla, Jira, Quality center, Test director etc.
9. Learn at least one reporting tool and add it to your CV.
10. Mention your automation skills like QTP, selenium. These days candidates having automation skills are given more weightage.
11. Include certifications related to software testing for e.g. ISTQB, CSTE etc. Some companies consider these certifications as a mandatory requirement while searching for candidates.
12. Personal details should only consist of Name, phone number and email address.
13. CV should be easily readable.
14. Don’t make the CV in tabular format. Only the educational details should be in tabular form.

ETL Testing / Data Warehousing Testing

Introduction on ETL Testing:

ETL stands for Extraction, Transformation and Loading of data. In data warehousing, data from multiple data sources is extracted, transformed (as per the business logic and data definition of target database) and loaded into cohesive database. Data warehouse efficiently handles day to day data along with organization’s historic data which may be very useful in creating reports for audits and compliance’s, future market predictions, etc. Since data loaded is very critical to the organization therefore it is very important for ETL process to undergo testing whether the extraction and transformation logic of data is as expected and also the loaded data is meaningful and as per requirements. Therefore ETL testing is new testing field for testers to pursue their career and this is the correct time to gain knowledge about ETL and Data warehousing testing.

Importance of Data Warehousing:

As organization businesses are growing day by day which is creating more and more data therefore there is a need to retain data in well-organized manner so that it is available for company’s day to day business expectations. Thus organizations are required to practice best extraction, transformation and loading technologies to integrate historical, day to day and other business data into centralized target database. In order to achieve this, many companies are creating their own database using various ETL tools to make the process very efficient.ETL tools make the process of extractions from multiple data sources very comprehensive and then transformation is done based on the required business rules. This transformed data is persisted into cohesive database known as Data warehousing and process is known as ETL data warehousing.

In order to make sure that the scripts applied in the ETL tools for extraction, business rules for transformation and data loaded are correct, there is a need to prepare the required test plan and test cases. Organizations may gain confidence in their business after Smooth ETL process which can only be achieved by efficient testing of entire ETL process, which is well planned and executed by the team of test experts who are proficient in ETL testing.

ETL Testing Classification:

Irrespective of using ETL tools, ETL testing can be classified into following types:

• New Data warehouse project: This scenario involves testing of DW from scratch. Required test plan is created and functional points are identified in ETL functional documents. Accordingly test plans are prepared and executed by ETL testers.
• Adding new source to existing Data warehouse: DW has multiple data sources. Data from these sources is transformed and persisted in cohesive DW database. Adding new data source involves addition of new data source to existing DW. Here testing expectations are to feed data from new source that is compatible with existing business rules and DW.
• Migration of Data warehouse: Here underlying database is migrated, for example, say from Oracle to Teradata depending on clients trust on vendor. Here ETL test team is expected to run all the existing test cases and make sure all test pass without any roadblock. Moreover test team conducts the performance test to justify the fact that the migration project has benefits over existing database.
• Change of Business Logic: Sometimes there is the need to change the existing business logic or add new business logic in data transformation. Test team here builds new test cases according to the new logic and make sure that old functionality is not affected by this new change (Regression).
• New or Existing Report testing: DW is the best source to generate new reports for audits, compliance’s, etc. Thus testing of report generation procedure as well as report data is conducted by ETL expert testers to deliver the quality end product.
• Platform Migration: Sometimes entire DW is migrated from one machine to another machine, for example, migration of database from low performance to high performance hardware boxes. In such scenario ETL tester are expected to execute existing test cases with additional performance tests to make sure ETL process is not broken and there are no roadblocks for business as usual.

ETL Testing procedure:

Testing procedures for ETL as follows:

• ETL test team is provided with functional requirements documents.
• Test team does the validations and come up with test estimates.
• Test planning is started based on above information.
• Test cases are developed according to the given ETL test scenarios.
• After test cases are approved by senior member, they are executed by test team till the expected output is obtained.
• Performance tests are also executed by ETL expert test team.
• After successful completion of ETL testing, test summary report is prepared and handed over to the senior project team and testing tasks are signed off by ETL test team.

Over to you on ETL Testing / Data Warehousing Testing:

Like any other software application testing, ETL testing follows same testing principles and since this ETL testing is the niche skill required in the market therefore such resources are on high demand in the market. ETL testers are expected to have good knowledge of ETL procedures, SDLC, SQL queries and system performance testing. A human resource with all of these skill set is an expert ETL tester.

How to Perform Software Product Testing – Detailed Process and Methods with Examples

Software Products need their own unique approach to test adequately and correctly. Often times, teams treat them as any other software (i.e. internal applications built for a specific client or team; not accessible by the general public; non-revenue generating) and that is the starting point of trouble.

Software Product Testing needs a custom test style and strategy to add value. Software Product development and sustenance is in itself a complex ecosystem and to thrive testers need to adapt.

Software Product development challenges:

Here are some of the challenges that Software Product development teams face:

#1) Lack of control over user demographics, devices, environments, platforms, etc.: Software products unlike software built for specific stakeholders are not used in controlled and predictable situations. There are many just too many factors to take into account.

#2) Foggy product vision: Product behavior and features are forever changing and the journey to maturity isn’t clearly visible. Or the product is growing too rapidly that it spirals out of control that teams don’t know what is happening.

#3) Aggressive timelines: Due to heavy competition in the software product market, things have to move at a breakneck speed and teams must stay a step ahead of their peers. Otherwise, they are sure to lose out to the competition.

#4) Fear of failure: Software products are usually innovative. So, their success is not always a given. This is the reason companies can’t go all out in terms of budget, technologies, infrastructure, etc. They often have to hold back to gain a certain amount of immunity from failure or to even breakeven.

#5) Lack of actionable feedback: Since there are no stakeholders or business users or clients, so to say, it is difficult to understand what the end user may or may not like. Companies are constantly playing a guessing game and often have difficulty in bridging the gap between what they want for the software and what the customer wants.

These challenges affect all areas of product development, marketing, and sustenance- And they inherently impact product testing too.

To get ahead in the game, this type of testing has to take five key points into account:

• Speed of development and releases
• Short term and Long term product goals of the product
• Extent and nature of competition
• Target audiences and their environments
• Requirements – Functional, performance, security, usability, configuration, etc.

Before we go into more details, let’s understand product life cycle (This is a generic product lifecycle and not specific to software products but software follows a similar pattern):

A good Product Test Strategy/Approach should take into consideration the current stage of the product in its life cycle.

Example: A company XYZ’s product is a defect tracking software called ‘TrackFast’.  It is a new product and the first version is set to be launched as a cloud and on-premise solution. TrackFast works like any other defect management system and is built for both Mobile and Web access. Currently, there are 2 to 4-week sprints at which the product is created in parts. You are on the testing team testing ‘TrackFast’ before it meets its customers. The testing involves checking functionality, performance, and security.

To summarize, these are the parameters you are working with. Or if you prefer, this is your context

Let’s see how to test at each stage. This is product test process, method, or life-cycle at each stage.

Stage #1) Product Introduction

Since this is the first time TrackFast would be going out into the market, the idea is to make a good first impression. So leave no stone unturned. Test everything and from every angle. In addition to that, lay the foundation for future testing.

A good test strategy at this point should include the following:

• Tests that validate the short term goals of TrackFast. “What does it need to be shipped correctly” should be at the forefront of the testing effort. Create End to end tests (front end, middleware, and backend) for thorough testing of every feature
• Tests that compare TrackFast with the competition (ideally this is the job of product owners but as a tester we can add our two cents. Also, this step is easier if the software has some peers already. For example: It is easy to compare TrackFast with Bugzilla or JIRA or other legacy systems. But let us say I am creating an app that does something unusual like being able to predict when a baby is hungry or cranky :), it might be hard to find an application that you can use as a baseline)
• Platform, browser and device compatibility tests
• Tests for ease of installation, set up and getting-up-to-speed
• Tests for performance, security, and usability
• Integration Tests if it interfaces with other systems. A simple integration example is that Defect tracking systems often interact with email clients to send notifications
• Plan for regression– It is a good idea to flag or mark critical tests that you think will be a part of future regression cycles and think about automating them for future releases
• Plan for known issues (are you going to be adding them to the backlog or handling them as CRs, etc.)
• Flexibility to change when the product progresses to the next life cycle stage.

It could sometimes be a long wait before the product goes out, so use all the time you have to do as thorough a job as possible.

3 Intangible Benefits of Using a Bug Tracking System

Can a Defect Management Tool Make You a Better Tester?

I am not a big fan of tools that are single-purpose. Whether the tool in question is a kitchen gadget or a work management software, you want it to serve you multiple ways.

The benefit of a defect tracking tool is not just effective management but, did you know that defect tracking tools could help you be a better tester? 

Firstly, Why to Use a Defect Tracking Tool?

In the absence of a Bug Tracking Tool, teams use spreadsheets to report, track and transport their bugs. While this might be a good temporary solution for small sized teams and projects, this is not a sustainable method.

Here is why.

Spreadsheets/Excel sheets pose a ton of challenges when you use them as your primary method of defect tracking and management.

To name a few of them listed below:

1) Too many bulky emails: Does this ring a bell? Excel sheets with screenshot attachments are sometimes over a few MB.

I often had these spreadsheet attached emails sitting in my outbox waiting to be sent or receiving a mailbox full alert as soon as I got one.

2) Lack of real-time visibility into bug discovery and progress/status: We don’t hear of an issue as soon as it is found. We also don’t know if an issue has been retested or returned, etc. real time.

Since there is no automatic alerting system, defects do not call for any attention to them unless someone is deliberately looking.

3) Work assignment issues: We don’t know who has what issue and what they are doing. If it has been picked up for resolution, what priority is set, etc. is never as easily visible as you would like it to be.

You might have to call or email or send an IM to find out what is happening.

4) Lack of a central repository: Too many folders, release-wise, module-wise or something-else-wise.

If you want to get back to a defect that was reported in the previous release or maybe a few releases behind, which was commented on by the developer in a certain way- you are simply playing a guessing game as to where the defect might be.

Even if you did find it, you might not have all the comments on it, all the history of it, etc.

5) Manual gathering and consolidation of defect statistics for insights into Quality of the product.

Imagine collecting raw defect data from each team member, entering into an excel template, organizing it to show a pattern or trend, and finally plotting a chart or graph. This process is time and labor intensive. And also, rigid.

Say if your team wants to view a new kind of report, you are looking at the additional effort and creating new templates, etc. So you are really limited your choices of what defect trends you can and will see.

Teams will no longer be inclined to invest time in monitoring and measuring and this means lack of visibility and confidence about the quality of the product.

Some problems could be solved with the use of a shared document on a remote/network drive, but not all. So, most test teams use a defect tracking tool to handle this process effectively.

Defect management/bug tracking tools offer a single point of truth for all your defects, provide real-time updates, aid collaboration with the team members, trace the defects back to the requirements and generate real-time reports.

Everyone knows about this, what’s new?

Here are some great ways you can make your bug tracking tool multi-task.

3 intangible benefits of using Bug Tracking Systems

I guarantee you that the defects in your report will be superior, valid, and easier to understand and will have a higher ‘picked-for-resolution’ rate.

#1) Understand defect trends

We are not talking defect density or defects per requirement, etc. We are talking about getting a deeper understanding of the system under test.

Let’s say you are new to testing an application. When you are in the process of understanding the system, check out your bug tracking tool for the kind of bugs previously reported.

Pay attention to some of the following points.

• Is there a component/module/functional area of the application that recorded more bugs that the others?
• Are there platform/compatibility related issues before?
• Are testing teams allowed to make enhancement suggestion? Check if testers before you did this?
• Were there environment problems and are they treated as typical defects by this team?
• What was the defect turn around? How much did take between defect reporting and fixing/closing?
• What is the average age of the defects?

#2) Understand defect reporting standards

Now, every company, every project, every team and every individual are different.  So, even though a few common guidelines on how to write defect reports exist, nothing prepares you like your own in-house research does.

How do you do that?

Check your defect tracking tool for the following:

• What defect reports got returned as “Not enough information”?
• What defects were outright rejected by developers as ‘Not a defect’ or ‘works as intended’. And, why?
• What enhancement suggestions were considered?
• What defects are still open?
• Did reports with screenshots have a higher rate of being fixed?
• For a defect, if the developers changed the severity, check out why? This might let you know what is ‘serious’ for the team and what is not.

#3) Prevent duplicates and invalid suggestions

Once you know your application, your team’s work style, your development team better you are automatically a better tester.

This way you will know what is already reported or what has already been suggested and rejected.

You can now focus your energies on uncovering new bugs, exploring the application deeper and tailor your reports in a way that you get through to your development team better.

Conclusion

Defect Management system, when used right – as a tester, you understand your ecosystem better and as a team, it will improve the overall efficiency.

Therefore, if you are still using the primitive spreadsheet method for bug tracking, it’s time to change.

The choices for bug tracking tools are many.

• If using a test management tool you are going to have access to defect tracking as well. You are good to go!
• Some companies create in-house bug tracking tools. They are similar to the commercial ones available. So, they do the job just fine.
• Commercial, yet affordable tools. E.g. JIRA or FogBugz
• Finally, if all your team needs is a tool for defect tracking and if the entire testing is still maintained manually, your best option is to go with an open source defect management/bug tracking system.

I hope this article has persuaded you into thinking beyond your defect management tool as a spreadsheet alternative and treating it as a huge historical data asset.

QTP’s Object Identification Paradigm – How QTP Identify Objects Uniquely

There are 3 buttons and 2 text boxes along with various other elements in this dialog.

In the previous examples, when we entered the user name and password we saw how QTP recorded the same operations in terms of programmatic code as well as a table in keyword view. Now, during play back how does QTP know that the value we provide as Agent Name or Password has to go respectively in those edit boxes. Or how does it know which button to click to submit the values entered?

Let us try to find an answer to that.

It is clear that QTP somehow remembers which object to act on. The way it does it is, it stores the object in the AUT as a test object. It then examines its properties and classifies the object. For E.g.: when it encounters the OK button it examines its properties and based on these, it classifies the object as a ‘WinButton’.

QTP has a predetermined set of properties that it learns/stores for every class of object it identifies. There are 3 aspects to this:

1. Mandatory properties: This is the list of properties for a certain class that QTP always stores. We could say that this is the object description. It also checks this in conjunction with the parent object to see if the description is sufficient to identify the object uniquely.
2. Assistive properties: In case the description of mandatory properties is insufficient to identify the Object a set of non-mandatory properties will be added to the description one after the other until there is enough data to identify the object.
3. Ordinal Identifier: If the assistive properties also do not result in unique identification of an object a special ordinal identifier is added by QTP, such as the object’s location on the page or in the source code.

So, this is how QTP forms Test Objects. It uses this Test Object description to search for the objects to act on during a run session. It chooses the objects that match perfectly with the description it contains. These objects are called Run-Time objects.

Unless your application has changed significantly the Test Object description that QTP has is sufficient to find an object.

For the WinButton object that we have in our Flight app, let us see what properties QTP has stored. This information is available in the Object Repository. Menu option “Resources->Object Repository” will launch the OR for us. Alternately, you can use CTRL+R or click on the icon.

it stored the ‘text’ in the WinButton as its description to identify this button at runtime.

For more complicated applications, the tester can add or remove certain properties to make the description robust enough to identify the object at runtime more precisely. To do this, simply click on the ‘+’ icon.

All the other properties of the object will be displayed. The user can choose to add one or more of these properties.

There is also something called “Visual Relation Identifier” in the OR screen for the WinButton properties.

This is a feature that further supports the object recognition according to their neighboring objects in the AUT. Once set, this creates a kind of link for the less stable components in your AUT with the objects that are more uniquely identifiable. QTP will identify these objects as long as they maintain their relative position to these unique objects. To set a kind of positional link we are going to have to click on this column in the OR a screen comes up:

In the screen select the ‘+’ sign to add an object with which you want your test object to have a positional link. I will choose “Agent Name” and say that this object should be above “OK”button.

Now, in case some properties of OK button changes in the future, QTP will identify it if, “Agent Name” is above it.

Smart identification:

This is the mechanism employed by QTP under one of these two situations. The description for an object that QTP has:

1. does not match with any run time objects
2. Matches with multiple objects

This is a little bit of an advanced concept, so we will get to it at a later time via some example for easy and elaborate understanding.

Ordinal identifier:

This is a numeric value that depicts the relative order of the object with objects that have a similar description. If an object 1 and Object 2 have the same mandatory and assistive properties, then the ordinal identifier will be used to recognize the object uniquely. This value is related to the other objects of the screen, so in case anything changes in the screen, this identifier might not come useful.

It should be noted that, if the mandatory and assistive properties are enough then an ordinal identifier is not assigned during record. It can be added later on by clicking on the respective column for the object in the OR

There are 3 kinds of ordinal identifiers:

1. Index: this is based on the order of appearance of an object in the application code
2. Location: based on the location in a screen or dialog or page
3. Creation Time: This is used only for browser objects. In case 2 browsers with similar properties exist, then the one that is created first and next are considered.

For example, Let us understand how ‘index’ identifier works in our Flight applications login screen:

These are the following components:

As you can see, the static text and the edit boxes have the same ‘text’ property.

If I know that one of them is a static text and the other is WinEdit object, then there is no problem at all. Say if all these are treated as WinObject then I will have to specify which object to act on. This is only going to happen when the mandatory, assistive and smart identification have failed. So in order to tell QTP which is what, I am going to assign an ‘Index’ ordinal identifier. I will do so from the OR.

I will set the Agent name static text identifier as 0 and for the editbox I will set it as 1.

This is how it looks:

So if I need to access the static text then I will do so as follows:

WinObject(“text:=Agent Name:”, index:=0) – This will refer to the static text

WinObject(“text:=Agent Name:”, index:=1) – This will refer to Edit box

The same theory applies to Location identifier too except that we will choose the location in the window to determine the numeric value that is applicable to a certain object.

Configuring Object identification properties:

The mandatory, assistive properties and ordinal identifiers to be considered for an object of a certain class to be recognized can be configured by using “Tools->Object Identifier”. We can also set the smart identification properties through this window.

The window looks as follows:

As can be seen in this above image, the environment can be chosen from the drop-down box. Once that is chosen the classes of objects in the corresponding environments are shown in the list. After an object is selected, the mandatory and assistive properties are displayed. The user can Add/Remove additional properties to this list.

Also smart identification can be enabled/disabled for a certain class of object when needed. To set the ordinal identifier there is a drop-down that can be chosen to identify the object using Location, Index or Creation Time (only for browser type only).