Tag Info

Hot answers tagged

23

In addition to what everyone else has said, it's absolutely realistic. With respect to what the hiring agencies are telling you, here are some reasons you could find difficulty convincing a developer that they want to be part of the test team: if your automation specialists are paid significantly less than your developers, you'll be asking any developer ...


13

There are plenty of testers who have learned to develop and there are also many testers who began their careers as developers. It is absolutely possible to find these kinds of people. There may be other hindrances however, such as availability in your area who have all of the skill-sets that you require, especially when it comes to specialized skill-sets. ...


11

For hacking WebDriver without real production purpose, you need to find some task that really motivates you. Don’t forget, WebDriver – is not only about test automation, people use the tool (not so widely) for many different purposes: crawling some data from websites, semi-automating real job-related tasks. For instance, a girlfriend of friend of mine ...


10

Yes, its realistic to find these folks. They form the majority of the teams that I've lead. You may want to adjust the title to be Software Engineer in Test, or just Software Engineer. In my org, the pay scale, and prestige for the software engineers in test are the same as software developers.


9

Strictly speaking you don't need to know how databases work to work with any automation tool. But without an understanding of databases and the ability to query them, you block off a large source of extra information you can use for validation. Some examples: Your application takes a person's name and contact details and stores them in three tables (for ...


8

Yes, it's certainly realistic to find such folks. I am one, and I've hired many. What is more difficult (and might be what the Agencies are saying), is to convince a current developer to become a tester. That sort of career change is a challenge, as is any career change. But there are many, many testers with automation experience who used to be developers ...


8

elefont, Trust in a test suite ultimately comes down to a few things: does it miss important problems it should have caught? does it report errors that aren't really errors? is it brittle? does it report useful information? (this is the most important factor, in my view). Dev code reviews can help, but they're probably no better or worse than in-team ...


8

Your application uses an API to interact with the database. It is possible to write your API in such a way that it presents correct results to the application and yet still uses the database in the wrong way. For example, imagine a database with an EMPLOYEE table and a MANAGER table. The tables are alike -- e.g. each contains a first name, last name, ...


7

Extending and maintaining automated tests costs time, but if your team are slaves to updating tests you are doing it wrong. :) One of the biggest reasons to create automated test coverage is to create a fast feedback cycle loop. Letting the test-team fix the tests afterwards slows down this process and will always lag behind. There is a high risk the tests ...


7

See if your test framework gives you a way to parameterize tests. Many test frameworks allow you to supply the values using a "data provider" method or object or class that you write yourself. If you have a framework like that, see if you can use its data provider mechanism to supply the values. The usual mechanism is that your code fetches the values from ...


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

While the entire system isn't under your control (which is clearly the superior option), it might still be possible for some slice of the system to be under your control. You say it's a payroll system. Can you create a "Test Company" that everyone else would agree to leave alone? Can you create "Test Employees" that everyone else would agree to leave ...


6

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 ...


6

Selenium is a tool that remote-controls a browser. You can use it to simulate a user interacting with a web site. JUnit is a framework for writing Java unit tests. It takes some of the grunt work out of organizing tests and generating reports. You can express each test as a method on a class; typically, you have multiple tests per class. JUnit will run ...


6

A lot of this will depend on if you are getting a good return of investment from your third part testers and testing scripts. If the end result if a good regression suite with the ability to vary inputs and conditions at a reasonable price then there is less urgency to take the automation fully in house. Even if the third part testing scripts provide a good ...


6

You're going to get a lot of "it depends" answers for this. Whether it's better to stay with primarily third-party automation will change depending on the quality of your third party automation providers, the nature of your business applications, your internal infrastructure, the method your third party people use and a whole lot more. Some of the factors ...


6

This is one of those questions which has multiple valid answers, as well as being a common problem for test automation engineers. The approach you take should be influenced by your knowledge of your user base: Do you know which configuration settings your users use? Are there known configuration settings used by your largest customers? Are there common ...


5

You should never run automated tests against a website for which you don't have permission. The site owner could consider it a denial of service attack or an attempt at hacking. In theory, they could sue you or ask your ISP to drop you. If you do this using a company computer, you could put your company in jeopardy. Don't. Here are three sites designed for ...


5

There's a few extra factors here that can impact the way you handle this problem: Do you get results for each test as it completes or do you have to wait until all tests complete? Do you have multiple machines on which to run the tests (and is it possible to do this) or are you tied to a single system running your tests in sequence? Can you break your ...


5

Imagine a jackhammer with a Phillips-head screwdriver welded onto the handle. You could, in theory, use this modified jackhammer for screwing things together, but you probably wouldn't want to. JMeter is a tool for performance testing. Selenium is a tool for functional testing. I talk about the differences between the two kinds of testing here.


5

You did not provide a lot of detail about the relationship between the logging system and the processing system, so my answer is going to be general/vague. I would try the following, in this order: Educate your management. You have a good reason for how you structured your tests. Explain what they can and cannot infer from a 100% failure rate. Explain ...


5

Wouldn't any data inconsistencies expose themselves in the application itself? Maybe, maybe not. I've seen cases where applications lost some data after you've logged off. So while the UI looked fine, the database was actually incorrect after logoff. In addition, are you sure that every single element in the database is being displayed in the UI ...


5

There's no real answer here. You should ask whatever your specific skills will command in your specific market, and for the specific job you are seeking. Explore local job sites to see what is being offered in similar positions. If there is an equivalent for salary.com in your part of the world, look there.


5

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 ...


5

It depends. If you're automating against an API, you can start as soon as the API calls are stable (the call names and required fields are decided). If you're required to do GUI automation, there's generally no point starting until the GUI is stable - for agile projects that usually means that GUI automation will run a sprint behind application ...


5

I think you want to pick the framework which has the most active development and the most documentation resources on the internet. Of-course you first need to check which framework fits your requirements, I would pilot all for a short while (starting with the most active one. If you have multiple candidates.) Which is more popular: Number of (recent) ...


5

The approach I've seen most often is to have the unit tests as a separate project in the application solution, so they can be run against production code as part of the build process, but are not included in the production code. Some of the reasons for the separation are: Logical separation. You want your unit tests to catch issues with initialization, ...


5

I have used Selenium and TestNG in the past to manage a lot of my automation and as Siva mentioned you do have the basics down. While TestNG is one of the most common Frameworks out there, it is not the only one, and you can use whatever one works for you. So long as you can import the Selenium drivers you can use any framework in which you are familiar, ...


5

Unit and system test automation is different, but at least a few of the unit test anti-patterns apply, such as concentration on happy-path scenarios. Thanks for including that link! In the automation I have implemented, I was forced to implement GUI automation due to the structure of the legacy Java client-server systems I was testing. However, these are ...


4

In a word, "No". Some more detail: •Increases the agility of development I've never seen this as either a goal or an outcome of automated testing. Typically, automated testing is used for regression - to provide some level of assurance that previously working software has not been broken by new changes. This has no impact on the agility of ...



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