uTest Non-profit Partner Brings 150 Software Testing Jobs to the Bronx

extralargeIT job training non-profit Per Scholas plans to bring 150 new software testing jobs to the Bronx, New York, this Fall when it opens a large software testing center there.

According to a DNAinfo.com news story:

Per Scholas, which is based in The Bronx, and the IT consulting company Doran Jones plan to open the roughly $1 million, three-story, 90,000-square-foot software testing center at 804 E. 138th St., near Willow Avenue.

All of the entry-level jobs will be sourced from Per Scholas graduates, and the boom of 150 new jobs is widely expected to open a lot of doors not usually available in the urban Bronx neighborhood. Keith Klain, co-CEO of Doran Jones, hopes to see the center eventually grow to 500 employees.

Continue Reading

Testers Should Be the Bearers of…Good News

Interesting interview here from the good folks at SmartBear Software — Dawn Haynes, Principal Trainer and Consultant at PerfTestPlus, Inc., mentions that when she used to walk down the development hallways as a tester, devs would run inside their offices.

Why?

Testers are often the bearers of bad news and thus unintentionally paint themselves as negative ‘Debbie Downers’ in the process. Who’d want to stick around for a hallway chat…with that?! Dawn argues that testers have the obligation to themselves to be the bearers of “good” news once in a while even if their primary job is to find bugs and point out faults. Do you agree?

Check out the video below of her interview.

Continue Reading

Four Ways Testers Can Change the Developer-Tester Dynamic

Before reading, be sure to also check out the first part of this article which details common perceptions of and questions testers have about dimagesevelopers.

So we’ve examined some of the questions testers have about developers — for instance, ‘Why do they look at us as the competition?’ As testers, then, how do we begin to change how developers view us? There are a few things that we can do to help change the dynamic between ourselves and development teams for the better.

Use a positive tone of voice

The way you word your bug reports is very important, not just from an informational standpoint, but also because it will directly affect how a developer receives the information you’ve provided. With a positive tone and general terms, your bug report will come across as informational and helpful.

Avoid including your personal opinion

This is also a good general rule of QA/testing, but it’s definitely worth repeating here. It’s okay to disagree with how a feature or app works, but we should not always express our opinion on the matter. Our job as testers is to be objective and unbiased. Additionally, it is extremely hard to convey emotion and intent in a written bug report, so while you might be expressing a benign opinion, it might be interpreted as hostile or accusatory.

Continue Reading

Three Common Questions Testers Ask About Developers

In my opinion, the greatest challenge someone in testing or QA faces isn’t their complex projects, the tight deadlines, the heavy pressure, nor the workinDeveloper-Vs-Tester-4g environment they’re in. Sure, those things do all impact the life of a tester, but they don’t compare to a common issue facing every tester in the world:

A tester’s effectiveness and happiness can be made or destroyed by the working dynamic between tester and developer.

I’ve had the pleasure of speaking to and working with many a tester and the most common concerns I hear boil down to: “Why are developers so defensive? Why do they look at us as competition or enemies? How can we work with a team that thinks we’re out to make them look bad?”

Those are very valid questions that need to be answered. Let’s take a step back and examine the root of the problem, one question at a time.

Continue Reading

Testers: Follow Your Passion…Or Not

Some say “follow your passion,” others, “follow your effort,” “do what contributes” or even “forget passion, forget goals.” In my case, the advice ‘follow your effort’ worked best. But I consider Scott Adam’s point of view equally as important, of ‘work hard, fail, try again.’

Mark Cuban

Mark Cuban

Testing, my work passion, is not the first IT job that I had. Over the years, I worked also as IT analyst & manager, software developer and web support manager. The web support manager position was temporary by replacing someone who took maternity leave. When that person came back to work, the testing opportunity that came up was too good to miss since the company did not have a testing team then.

It took a while to build the team and the department, but testing was not a passion at that time. An interesting job? Yes. Passion? No. I kept working at getting better at testing, read everything I could find and trying new things all the time.

Continue Reading

6 Tips for Testers When Talking to Mobile Developers

I’ve said it before and I’ll say it again: It’s a good idea to keep the developer on your side.devtest

The end goal that both developer and tester share is the exact same in software quality, so if you’re a tester constantly at odds with the other side, not only will you not reach that quality zen that you so much want, but you’ll lose a lot of dev allies…and probably your credibility to the higher-ups in the process.

Since testers and developers have to play a team sport to get to this software quality ideal, especially when it comes to mobile which is here to stay, uTester Lena Houser has put together this must-see list over at uTest University of tester tips to note when talking to mobile developers:

  1. Treat devs the way they want to be treated.
  2. Do not interrupt and give them time to finish their task(s).
  3. Come prepared. Gather your evidence and facts to help build a case.
  4. Shrewdly communicate and present your findings.
  5. Do not be negative or arrogant.
  6. Testing involves a lot of ego management.

Be sure to also check out the full course over at uTest University to get all of the context behind these six steps to success when communicating with mobile developers. In the meantime, is there anything here that you’d add to the list? Be sure to sound off below in the comments.

 

Testers Don’t ‘Assure’ Quality, So Why Are They Labeled ‘QA’?

Quality Assurance. Testing. The two terms are used interchangeably in the industry and on job posting boards all over the world, but should they be? Quality Assurance

In short, no. At least according to many of our community members, which have debated at length in recent weeks whether folks should be labeled ‘testers’ or ‘QA professionals’:

  • [QA] is used way too often and it is usually used incorrectly. QA stands for Quality Assurance. Quality Assurance is process-oriented and focuses on defect prevention. It is a term typically used in manufacturing. We are in the defect identification and information providing business. We are not QA people. We don’t do QA. We are testers…we test!
  • The way I see it, ‘software quality assurance’ encompasses a slightly higher-level picture which (for example) includes adjusting management or development processes so that bugs are prevented from occurring in the first place.
  • QA deals with adherence to processes and organizational standards in order to prevent bugs in an application.
  • Quality assurance means more than testing in my view. It is management, programmers, leaders, analytics, and so on. They all chip in to make sure the final product is of some quality.

Continue Reading

Looks Like Testers Have a Case of the Mondays

In a recent interview from SmartBear Software, testing expert Keith Klain proclaims that “a lot of testers are overly negative and combative, and they’re only a deconstructive process in the constructive world of software development. And they let that affect them in a very negative way.”

Klain’s comments echo some of James Bach’s comments that some of the biggest challenges affecting testers today are, well…themselves.

Ouch.

Are some testers in need of an adjustment in mind and attitude? Is the biggest threat to testers’ success really themselves?

Check out the choice soundbite for yourself and sound off in the comments below.

So You Wanna Talk to a CIO?

While testers may not be the decision-makers within an organization, we have established the fact that they can be the ultimate advocates and can influence the final decisions.

But why would testers need to interact with CIOs in the first place? What issues would even come up, and how should testers have these important conversations with those in the upper echelons of the organization? Big credit goes to the Ministry of Testing who has put together a robust set of recent presentations from the big TestBash event in the UK, including this one from software tester and COO Keith Klain. The following session tackles these questions when testers just need to go to the top, and includes profiles of CIOs Keith has worked with in the past as a tester to tell the story.

Credit: TestBash (Ministry of Testing)

Top 20 Pieces of Advice for the Novice Software Tester

While many within the uTest Community of 100,000+ may be beyond the beginning stages of their career (in fact, well beyond that honeymoon phNovice Software Testersase), we know that everyone starts from somewhere. With that in mind, we recently asked our community to pay it forward and offer some advice for their newbie peers just starting down the path as a tester. Here’s some of the top responses from our uTesters:

1. Think of yourself as an end user.
2. Don’t be afraid to ask questions.
3. Always be curious. Learn new technologies.
4. Don’t rush. The time you spend in research, refinement & reporting issues/bugs is just as important as finding the bug.
5. Pay attention to details, even on a microscopic level.
6. Use EVERY resource available to you (i.e. uTest University, EdX, and lynda.com).
7. Acquire: knowledge, support software, devices and computers, equipment upgrades, test tools.
8. Learn from others (your peers).
9. Always be open to feedback.
10. When testing, focus on the unexpected data and actions to see how well the developer handles error conditions.

Continue Reading