Share Your Own Job-Search Story – Unnikrishnan Alungal – Harvard Business Review

Share Your Own Job-Search Story – Unnikrishnan Alungal – Harvard Business Review.

This blog post comes to us from one of our Facebook fans, Unnikrishnan Alungal. We contacted him after reading his insightful contribution to our jobs-related group discussion. In the post below, Unnikrishnan shares his experiences searching for an IT consultant position in the Indian and Saudi Arabian job markets. We invite you to share your own stories with us in the comments.

It was a late evening in 2001 — in the small Indian town of Kozhikode — when my friend’s father, Professor Salahudheen shared this advice, “Son, job hunting is a different art. It’s nothing like scoring marks in university. It demands specific skills and you need to develop these skills to win the game.”

As a fresh graduate in engineering, I was on my way to Bangalore, which was fast becoming the Silicon Valley of India, to look for a job. The Indian job market was growing significantly because of an influx of positions in the technology sector. The challenge was to find the best opportunity first. During my job search, I worked to make connections at every job fair I attended. I joined online groups and mailing lists, and expanded my skill set to suit market expectations. My strategy worked well, and I eventually found a position at Tata Consultancy Services, a leading multinational information technology firm.

Now in 2012, almost ten years later, I have started a new job in Riyadh, Saudi Arabia. My job-search strategy was vastly different this time around not only because of the rise of social media, but also because of our current economic climate. That said, the words of Professor Salahudheen still remained true, “Job hunting demands specific skills, and you need to develop these skills to win the game.”

I started my job search by making a list of the industries I wanted to get into and the companies I wanted to work for. I then used LinkedIn to search for individuals who were currently working in these industries or for these companies. I looked through their skill sets to make sure they aligned with my own — and figured out where I needed improvement. I then adjusted my resume to highlight my key skills (and used hard numbers whenever possible to showcase my achievements).

I also set up a personal job-search feed, which delivered positions to my inbox automatically. When a promising opportunity landed in my inbox, I used LinkedIn to learn more about the position. I not only researched the company, but also looked to see if I had any shared connections to any of the company’s employees.

I then worked to transfer my virtual connections into the real world — ideally, at a conference or networking event. Many LinkedIn groups, like The Enterprise Architecture Network and the Project Management Institute (PMI), organize networking events for their members.

Twitter also proved to be very useful. By following HR managers, placement agencies, industry news, and region-specific groups such as @psp_jobs@middleeastjob, and @reeduae, I was able to find listings as soon as they were available, which gave me a head start when applying.

To prepare for interviews, I recorded a thirty-second clip of myself, describing my skills, my potential, and my experience. I repeatedly practiced it aloud so that when recruiters called, it was ready and well versed.

By following the steps above, I was able to find my new position at Pink Elephant, an IT service management company. A few weeks ago, I was walking through the corridors of my office building and the security guard from another company approached me and asked whether my firm was hiring. He desperately wanted to change jobs. I shared my job-search experience with him, and he’s now started to get calls from potential employers. The steps that worked for me have now worked for him as well.

What have been your experiences trying to find a job recently? What’s different than when you’ve searched for a job in the past? What challenges are you facing? Please share your experiences in the comments.

Advertisements

QASymphony to Partner with Cohesion for Agile Application Development | Software Testing Tools Blog – Testertools

Check out QASymphony to Partner with Cohesion for Agile Application Development | Software Testing Tools Blog – Testertools

QASymphony http://www.qasymphony.com, a developer of SaaS-based software testing tools for Quality Assurance, announced it will partner with Cohesion(www.cohesion.com), a Cincinnati-based consulting firm that is a leading technology consulting firm that partners with clients to help them achieve growth through the optimization of their technology investments.

Comprised of some 200 consultants, Cohesion will deploy and recommend QASymphony’s new defect capture and bug reporting tool called qTrace, to its many client engagements.  Cohesion’s Director of Quality Assurance and Testing Services, Joseph Ours, states, “Partnering with qTrace gives Cohesion the ability to meet many challenges we find at our client sites.  Not only is qTrace an excellent tool for capturing and automating defect entry, but it’s a great way to document exploratory testing sessions inAgile projects.  qTrace gives testers the peace of mind to know that their actions are being captured and can be easily communicated to other testers and developers alike without the burdensome overhead of a video capture system, or the huge files a video would create.  Lightweight and easy to use, qTrace will improve the efficiency of testing tasks.”

Cohesion specializes in the banking and financial services, insurance, technology and retail industries. The firm offers both short and long-term project work and provides assessments, recommendations, program / project management, end-to-end delivery, resources and ongoing support in developing business applications.

“We evaluate a lot of tools on the market and we found qTrace truly unique,” said John Owens, CEO, Cohesion. “The tool promises to expedite our Quality Assurance process with a lot more accuracy. Our clients should see the immediate benefit in having their custom business applications ready for prime time by about 20% faster.”

qTrace is a defect capture and reporting tool for bug discovery that records all steps, screens, and system information associated with a defect. Early users found it cuts defect capture time by 30-50% and decreases fix time by 10-30%.

With an easy-to-use interface, qTrace provides the functionality to annotate bug fixes and complete reports that can be saved as a PDF or Word file or submitted directly to a bug tracking system. The tool offers out-of-the-box integration with the industry’s most popular bug trackers.

A 30-day free trial is available by visiting: http://www.qasymphony.com/download.html.

Demo Asia 2012, March 2012 by Epsilon Mobile

This article represent a friend of mine whose start-up named Epsilon Mobile http://epsilon-mobile.com

The DEMO conference is a technology conference that focuses on showcasing new products from both entrepreneurs and established companies. Many well-known companies have launched at DEMO and became household names. Over 21 years, DEMO has launched Adobe Acrobat, Netscape, Palm, Sun’s Java, Salesforce.com, iRobot, VMWare, ETRADE, etc

At DEMO Asia 2012, Epsilon Mobile takes self-publishing service a step further with the launch of the beta Papyrus in the DEMO Asia 2012. The new service is the very first to enable content providers to create and publish interactive content easily on iPhone and iPad at an affordable cost.

Testing in the Agile World with Vu Lam | Testing

Testing in the Agile World with Vu Lam | Testing.

Vu Lam is CEO of QASymphony. He has over eighteen years of software industry experience, including founding two outsourcing companies and building a nationwide infrastructure connecting Vietnam’s banks, stock brokerages, and commercial entities. In this Sticky ToolLook interview, he discusses testing in the agile world.

Sticky ToolLook: What are some ways in which bug reporting and test documentation differ for agile organizations compared to “traditional” organizations?

Vu Lam: With respect to test documentation, one significant difference is that in traditional organizations, testers usually design detailed test cases based on available requirement specifications before actually executing any of them, usually weeks or months later. In an agile setting, testers tend to adopt exploratory testing, where they combine test design, execution, and emerging learning. Test cases are still designed, but they are created in the minds of testers when they test instead of being written down beforehand. In a sense, this is similar to the way agile developers design their software. That is, they rely more on emerging design happening during coding and refactoring rather than following the instructions of design documents.

Why does this make sense for agile teams? Changes. Teams adopt agile processes for that exact reason: Changes are inevitable in their project. Think about it. There is no point in rigidly executing a test case if it is already out of date by the time you test. Besides the overhead of documenting it and keeping it up to date, it simply does not make sense.

Regarding bug reporting, there is no fundamental change to the process. Most testers in an agile team still resort to bug-tracking systems to manage bugs, and they still need to submit well documented bug reports that help developers reproduce and fix the bugs. However, testers on an agile team have to rely on multiple communication mediums with developers more often, rather than collaborating via a non-verbal or non-visual medium constrained by a complicated defect-resolution workflow. On some teams I have been a part of, we even used the same tracking system to manage both user stories and bugs. On yet other teams, we treated outstanding bugs of a sprint just like user stories. Simplification, however, requires the team to approach bug fixing just like any other task in an agile project: It must be driven by the value it brings to the business.

Sticky ToolLook: Agile organizations focus on communication, often aiming for regular, face-to-face feedback. What are some of the communication challenges specific to a testing team at an agile organization, and how can teams overcome those challenges?

Vu Lam: I know many testers are more comfortable dealing with use case specifications, test cases and emails, etc. than doing face-to-face communications. Sometimes, this is simply their working style. Unfortunately, more often than not, this is due to a lack of understanding about agile processes and a tendency to stick with old habits. To get over these, testers have to educate themselves as much as they can about the values and principles of agile development and understand that they, too, have to embrace these values and principles for agile development to work. Regular, face-to-face communication is just one of the principles of agile development that testers have to adopt.

Yet, with global teams, face-to-face communication is not always possible. While local teams can and need to practice it, distributed teams have to learn how to maximize effectiveness and rely on other communication venues such as phone, IM, collaboration tools, visual correspondence, and documentation of ideas and test results.

Sticky ToolLook: How should a global organization handle agile? That is, if teams (or maybe even individual members of a team) are not in the same physical location, what can they do to improve their communication and documentation practices?

Vu Lam: Agile development clearly works best when the team and even their customers are co-located. Most of the literature on agile development does not deal with the challenge of distributed teams, so teams are generally left to solve this on their own. That said, I think there are a few practices that agile teams may use to alleviate the problem.

First and foremost, they can deploy a task collaboration system that shows clearly, in real time, who is doing what and their status. This is to empower project members to take ownership of their work and report progress, making it less of a coordination burden for the project manager. At the same time, it ensures that team members at different sites, while not seeing and talking much to one another, have the big picture of the project.

Besides the regular same-site daily meeting, they should have daily meetings among the leads of different locations. This is to ensure that information and issues are quickly shared and addressed. Yet, this introduces new problems with globally distributed teams—namely, that of time zone differences, language barriers, and cultures.

Again, teams need to effectively leverage venues such as phone, IM, and other collaboration tools. But these can’t solve some of the issues that arise from language and cultural barriers. I feel that, in conjunction with these venues, the effective use of visual communication is key. And this is what we mean when we talk about visual communications: How better for a tester across the world to get his point across than to literally capture his test steps, keystrokes, and screen movements annotated with comments, all in one document that his audience has access to prior to the discussion?

Sticky ToolLook: How do agile practices improve the feedback loop between finding and fixing bugs?

Vu Lam: Having a short feedback loop is essential to agile development, so it comes as no surprise that agile processes come with multiple practices enabling feedback to emerge as quickly as possible. Communication practices like daily standup meetings and an open workspace are the first that come to mind, but again we have the issue of globalization. We believe based on our experience that visual communication also minimizes the time between finding and fixing bugs.

Sticky ToolLook: Are there any challenges that agile practices actually introduce to software testing? If so, how do agile teams overcome or work around them, and what are some potential long-term solutions?

Vu Lam: The gist of agile development is about delivering value fast. For software testers, it means they have to find ways to continuously add value to the project. It is simply no longer possible to follow predefined checklists from a preferred one-size-fits-all methodology. They have to constantly ask themselves whether the things they are doing and how they are doing them support, defeat, or simply do not matter to that purpose.

On the other hand, they need to assist in making sure working software can be released quickly and regularly even in the face of changes. Self-educating on how to plan, design, and execute tests on the fly is essential. They have to learn to embrace changes and act upon emerging discoveries about the system. They can no longer rely on thick requirement documents or assume they have the time to create and maintain giant test cases. And they have to learn to engage more often in visual communication irrespective of location, for it is usually the fastest and most effective way to get the most up-to-date information across among team members.

Agile development works but is not without challenges. Yet, there is no shortcut, only solutions.

Get your ideas heard & influence qTrace release schedule

Further info at http://support.qasymphony.com/home

We’re glad to see the increasing number of features suggested by qTrace users like you. We were thinking, it’s about time we should have an announcement to let you know how we prioritize and build the features you desire 🙂

How to influence QASymphony’s release cycle and get updated on progress

For every major release we encourage and display customer comments and votes openly in our Feature Requests forum and review our most popular voted issues on a regular basis.

And by sharing your ideas, suggestions in the form of feature requests in our Feature Requests forum, you have already influenced our release cycle. 

Find out if your feature request already exists. If it does, please vote for it. If you do not find it, create a new feature request online. Subscribe to it to keep updated on progress of planning, implementing and releasing the requested features.

How QASymphony chooses what to implement

However besides community highly requested features, we schedule releases based on a variety of other factors … so if you are wondering what our thought process is … it goes a little somethin’ like this:

  • Direct feedback from face to face meetings with customers, and through our support and sales channels.
    • We value your feedback, whether it be from a large company who likes our product but needs some tweaks and customizations for their environment – or from user feedback we hear at the customer service desk, sales meetings or right here on our website.
    • Why do we value your feedback so much? As a company it sounds nice to say that, but we really do crave the product feedback that you have so much because QAS knows that our product users are why we build the products we are working on – so if you need them to change, we listen!
  • Impact of the proposed changes on the application and its underlying architecture.
    • Sometimes a change proposed by the community may have some technical problems with being implemented in the first place. It doesn’t mean we’ll totally abandon trying to get it coded, but we might not be able to get to it in the current release until our brainy dev team sorts it out.
  • Our long-term vision for the product.
    • The last big question we ask ourselves is … does this feature fit with the core intent for our product? In other words, are we changing the very nature of the product or muddying the waters by adding just too many bells and whistles? If we think a particular feature is not fitting for our product we’ll let you know and get a discussion going about it with you. Hey, we’re an open minded company after all – maybe you will change our view about the request.
Don’t hesitate to share your thoughts with like-minded folks. We know you have ideas. Let’s hear.
 

Thanks for reading, and enjoy tracing!
QASymphony Team

Where to get latest version of qTrace?

Further info at http://support.qasymphony.com/home

You currently have 2 ways to get qTrace’s latest version.

In case it’s the first time you install qTrace30-day trial page is the one place on the website where you can download qTrace. Although the page is mentioned as trial, qTrace downloaded from that page is the latest full featured qTrace version.

What if qTrace is already in use on your computer? Click the “check for updates” on the About screen to see if there is a newer version of qTrace is available. qTrace will automatically check and let you know in seconds.

2.png  

qTrace_latest_version.jpg

or the new version has just released

update.png

 

In future releases, qTrace will be able to detect if there is newer version availale, suggest users to upgrade and upgrade itself to the newer version at user’s discretion.

To stay updated about newer qTrace’s releases and features, subscribe our Release Notes Forum.

Thanks for reading & happy tracing !

QASymphony Team

How to avoid typical mistakes while submitting bug via qTrace to trackers

Further info at http://support.qasymphony.com/home

Aims to get you gone through typical issues faster on your side, here’re some typical mistakes while submitting bug to your preferred tracker.

#1. Input mistaken web service url for integration

We should note that if URL to login from web browser sometimes looks like the Web Service one. Take this case as an example, UI web url is https://jira.qasymphony.com:8443/secure/Dashboard.jspa , the Web Service URL will be https://jira.qasymphony.com:8443

The Web service URL schema depends on your setup. The common schema is http://yourserver:portnumber . Contact your administrator to get the correct Web service URL. 

Also please make sure the username/password you put on settings dialog is the username/password you can use to login from web interface.

It doesn’t work..
UI_web_url.png

It does work..

web_service_url.png

 

#2. Bug’s info not placed in the correct field

Look into the following case: 

When submitting a defect to VersionOne through qTrace, the Summary/Trace Steps are not placed in the correct field in the VersionOne defect. The steps are placed in the “Description” section rather than the “Steps to Reproduce” section.

mapped_field.png

VersionOne does not allow qTrace or other applications that want to integrate with Version to query its custom fields either. So qTrace has no knowledge about whether there is a custom field named Steps to Reproduce on VersionOne or not (some admin will add this field and possibly name it a bit different than “Steps to Reproduce”, and some will just use default VersionOne configuration that does not have this field).
At this point, users may have to manually update the ticket on VersionOne after submitting it to Version. In future releases, we are considering allowing users to map fields on qTrace with fields on VersionOne, save and share this mapping settings with other people in team.

Learn more about other trackers at Help file embedded in qTrace tool bar at Share Defect › Submit Defect to Defect Tracking Systems