23

Java Bean, I think you may want to ask yourself a few questions first: do you want to be involved in testing or in programming? In my experience, colleges are usually less than stellar in the QA domain, and tend to assume that testing is "any warm body" and useful to familiarize someone with an application before they start coding with it. do you like ...


23

Good and Interesting question. Here are some to make the tester's job easier: Developers should perform basic testing before giving the product to the tester. Include QA from the beginning of the project, not when the product is ready to test. Work as a Team, not as two different departments [Developer & QA] As the developer, never ask the QA to ...


17

Like Sam points out experience with SQL and/or with MySQL will greatly depend on the project and/or the company with whom you hope to work. SQL skills are one aspect of Software Testing that focuses specially on technology. James Bach, an expert in the field of Software Testing with 20+ years experience, published a Tester's Syllabus for those who are ...


17

I think it is not a good idea because regression testing is carried out once you complete integration and sanity testing followed by system testing. No, it is not necessarily a bad idea. You should not consider it as a bad idea solely based on the order in which tests are carried out. By definition: Regression testing is a type of software testing which ...


14

Treat them as equals. I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.


13

You describe several skills that are advantageous in a tester: analytical skills, the ability to find flaws, and tolerance for repetition. You also seem to be interested in testing. A potential disadvantage from your own admissions: reluctance to take ultimate responsibility and, to a lesser degree, discomfort with starting something from scratch. You ...


13

Just a few quick ones off the top of my head: Run the code they've completed at least once on their machine before marking it as 'Done'. Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written Encourage QA to participate in sprint planning/grooming, design ...


13

I've worked in both roles for a while and my recommendation is: Pair (before coding when possible) on test plans See QA as an asset that is protecting you and customers from the mistakes we all make Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding Don't assume that they can pass ...


12

I cannot speak for the industry in general, but at places I have worked, developer-initiated smoke-testing is a common practice if builds delivered to QA tend to be unreliable. I had a job as a test lead on a team that required developers to smoke-test the builds. At first it was a painful process, taking up most of a developer's time for an entire ...


9

I never see common agreement on any software-related titles. In some shops where I have worked "Architect" implies a thinker, not a doer. For QA Architect, it means someone who thinks about QA, researches and suggests improved methods and metrics. Sometimes it's someone who trains others. In other shops, "Architect" just means "very Senior". It's the top-...


9

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


9

Professors make this suggestion. I suspect many of them don't actually know what a QA career entails since most of the professors I know are a bit divorced from the world of business. For more information, I'd suggest reading this very similar question (Fundamental Requirements For an Entry Level QA Engineer) and my response to it. Some specific skills ...


9

You could start with unit tests, while the application is being developed. In Java you can use JUnit for this. If you don't have a fully functioning system yet, you can use mocking to mock objects. In Java this is done with Mockito or JMockit. Look into unit testing and TDD (Test Driven Development). Once you are ready to integrate different components, ...


8

SQL is specific to the project you're working on. Knowledge of SQL may or may not be applicable to a SQA position. I would say there are probably more SQA positions than not that don't have that requirement. The most important thing for an SQA position is logical problem solving skills. Especially for entry level SQA positions most of the focus will be ...


8

I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would ...


8

My Advice: Do not communicate your disagreement by email Schedule a time to meet with your manager and have the conversation with them. Emails do not work well for this sort of communication as it is not clear what the all important 'tone' is and it is also one-way at a time which does not work very well for difficult conversations. The manager may also ...


8

I'm always on the lookout for grammar and spelling errors - purely because we're here to assure quality, and typo's aren't professional. It's usually not the developer's fault because they just copy + paste it from a requirements document or something similar, and testers are more likely to catch it. As a consumer - if a company can't spell properly, I won'...


8

I think the right answer is it depends. It depends on where you work and what you are going to do as QA engineer. At some places it is just manual testing. At some places it is manual testing + UI automation. At some places it is manual, automation, API ,database testing. At some places it is just another software engineer position and same coding skills ...


8

Does it matter? Sounds like impostor syndrome. Your probably less confident about your skills than you should be, it is the Dunning-Kruger effect. In my book, you are good enough at anything, if you accept your current skill level. Have a plan to improve. Act on your plan weekly.


7

Xenu Link Sleuth (http://home.snafu.de/tilman/xenulink.html) can do that and more. It's easy. It's fast. Best of all, it's free! (Free as in $0, but not Open Source)


7

I am working under the assumption that you would be familiar with the language the tools are being written in. If the team you are on already is writing unit tests a good place to start might be with them. Talk to the developers that are writing the unit tests and get an idea for how the underlying code is working. In the process of doing this start ...


7

A few thoughts based on my not-quite-ten years experience as a tester and automator: Learn the principles, not a tool - If you understand the principles of automation and how it works, you're going to be in a much better strategic position than if you simply learn an automation tool. You could do worse than to dig through Joe Strazzere's blog and Alan Page'...


7

This is a simple point, but very effective: Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect. It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.


7

You may be getting the previous page source code because the getPageSource() method is called before the page arrives to the page you want. One thing I would like to suggest is before getting the pagesource of the webpage check whether you have navigated to the correct page like: public static void testLogin(WebDriver driver) { if(driver.getCurrentUrl(...


7

Very well put by Yu Zhang. I just want to add my two cents to cover another aspect of it. Even if we think that the manager's suggestion is incorrect. Before reacting, it is always good to spend some time to think about the suggestion and come up with all the benefits and drawbacks of following the instruction. Apart from that we should also discuss our ...


6

It's always a challenge to change careers. And as a hiring manager, a red flag always go off when someone wants to change careers and get hired onto my team. I see a few here. You say that you are burned out as a developer. That's understandable. So are you considering QA as "easier"? Less likely to cause burnout? Be prepared to discuss this in depth ...


6

Your first bullet assumes that you write the code before you write the tests. That's a common assumption, but note that you have a choice about whether it's true. If you change the assumption, if you write tests before you write code, you can wear your "tester hat" without being (quite so) biased by the code you've written. You can do this on two scales: On ...


6

Welcome to SQA. I assumed you're a tester :-) In short, do devs like being bothered by testers? Well, that depends on many things. If you find a bug and won't bother a developer to fix it or answer area around it, she might bother you to explain it better later, when you're busy. So it is in interest of both of you to find the right time. Finding the ...


6

I would start with what you have, the inputs and outputs, then start questioning. I like to go through a bunch of what if's, such as in your case "what if the database is unavailable?" or "what if the mail queue is full?" or something like that. If you can't come up with questions like that, then ask the developers "what didn't you test that you think I ...


6

There's no one true way to do this, but there are some common things you can do to get an overview of the system you're working with. My approach is to start with a series of questions (not in any particular order) Who - who is the application intended for? Knowing who the users are tells you a lot about how they're likely to want to use the software and ...


Only top voted, non community-wiki answers of a minimum length are eligible