I'm starting a new QA engineering internship and I've been tasked with automation tests. I was going through the documentation for selenium and testNG and it seems straightforward and easy to pickup.

The only thing I find difficult is becoming familiar with the application that's being tested. There are always so many different methods and classes that make up an application that, unless you wrote it yourself from scratch, it would be difficult to know what methods are available, which ones to use, etc. At least in my experience.

But I've always noticed experience software engineers coming in, spend a few days, and they're able to develop new features, automation tests, etc...

So, I was wondering if there are any tips on how to get acquainted with the in(s) and out(s) of an application quickly.

I asked one of the experience Software Test Engineer and he said it's helpful to know how the application works manually first. But even then, to me, it would seem to take awhile to learn the application, then figure out what methods/class relate to a specific action within - which again, could take quite a bit of time.

Anyone have some helpful input on this?


  • 1
    Even an experienced software engineer won't know all the ins and outs after just a few days. They figure out the big picture and then focus on the area they care about.
    – user246
    Mar 11, 2014 at 12:50
  • Depending on the application, getting up to speed 'quickly' can be extremely difficult. Surely learning the requests and responses is simple, knowing if those are the correct request response is the hard part.
    – Paul Muir
    Mar 11, 2014 at 16:48

5 Answers 5


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 what parts of it they're going to use most.
  • What - what does the software do? What's it's main function?
  • When - and how often does it do what it should do? The tests you'll want for software that's needs to be available all the time is different than what you'd do for something likely to get occasional use.
  • Why - why is the software needed? This does overlap somewhat with what it does, but the difference here is that there's a reason the application exists, and that reason is going to guide your strategy.
  • Where - where is the software used? This doesn't just cover whether it's business or consumer software, it also covers things like is it web-based or desktop-based, will it be running over a LAN or WAN or will it be self-contained, and so forth. The environment - software, hardware, and human - tells you a lot about the conditions the application will need to handle, which in turn tells you where to focus your testing.

After I get the overview (the 10,000 foot view - as if you're 10k feet above the ground looking down) the next thing I do is explore the application with frequent reference to the user documentation, use cases, user stories, and requirements. At this point I'm not looking at classes, methods, or actions. I'm looking at how a typical user would interact with the system. If you're lucky, the application itself is self-documenting and you can figure most of it out from the user interface. If you're not (which can often be the case with business-to-business software and specialized software) you have to dig deeper to figure it out. The goal here is to figure out the area of the system that will give the best bang for buck when automated.

Once I've got a handle on that, it's time to start exploring the system with the automation tool. In the case of Selenium and TestNG, if you're working with a web application there's looking at the generated web page source for elements to hook into, as well as deciding on your framework - whether you're going to have a whole lot of granular tests strung together to form a pathway through the system, how you're going to handle dependencies between modules, how you're going to deal with balancing test code duplication and the need to keep tests independent (this doesn't have to be an issue with Selenium or TestNG, but with some of the big box tools it's very easy for it to become a major problem).

Then I start actually building coded automation. Usually the first thing I'll automate is logging in for the simple reason that just about everything I've tested requires the user to be logged in to do anything. From there, I'll start building test suites that cover the most common pathways through the application: log in and sell stuff, log in and run report X, log in and... whatever. At this point (anything from 1-2 days after I first encounter the software to a year or more later) I don't expect to be getting everything or even close to it. The goal is to get something which I and others can add to later.

The only other thing I'd suggest is looking at why you're automating. The usual reason is for regression testing, but there are other uses for automation, including building helper scripts to take care of tedious manual tasks, harnesses to run a common set of actions so you can work from there, performing the same task multiple times (I've built quick and dirty automation to do things like run and exit an application hundreds of times to try to track down an intermittent on-shut-down error, create thousands of products in order to test a receipt overflow, create thousands of transactions to test a payment processor hard limit to the number of transactions it could process in a batch, slightly less dirty ones for things like archiving log files on a daily basis so I didn't have to deal with waiting half an hour for a multiple GB log file to open, and so forth).

  • Great answer, just one addition to the list of reasons for automating. One of the main reasons for me is an early indicator. I like to add automation for the happy path of a broad set of functionality (rather than creating a lot of tests around 1 or a handful of features) so that I can easily run those build over build and get an immediate indication if those core scenarios are broken.
    – Sam Woods
    Mar 13, 2014 at 20:57

Becoming familiar with an application can be a challenge, but there are definitely ways to speed up the process. Here are some tips to help you get up to speed quickly with automation tests:

  1. Learn the application manually: As the experienced Software Test Engineer mentioned, it is helpful to understand how the application works manually before diving into automation testing. This will give you a better understanding of the different features and workflows, and how they all fit together. Take the time to use the application as an end-user would, and make note of any areas that you think might be particularly challenging to automate.

  2. Review the application documentation: Most applications come with some form of documentation, such as user manuals, technical specifications, or API documentation. Reviewing these documents can help you understand the application's architecture, functionality, and data flow.

  3. Collaborate with the development team: Developers are often the ones who know an application inside and out, so collaborating with them can be extremely helpful. Ask them questions about the application's architecture, design patterns, and how certain features were implemented. This will help you understand how the application is put together, and what areas might be more challenging to automate.

  4. Use tools to explore the application: There are a variety of tools available that can help you explore an application in more detail, such as Chrome DevTools, Postman, or Wireshark. These tools can help you understand how the application communicates with the server, how it handles requests and responses, and what data is being passed between different components.

  5. Start small and build up: Don't try to automate everything at once. Start with a small feature or workflow, and build up your automation suite gradually. This will help you become more familiar with the application over time, and allow you to identify any areas that might require more attention or testing.

Remember, becoming familiar with an application takes time, and it's okay to ask for help or clarification when needed. With these tips and some practice, you'll be developing automation tests in no time! Good luck!


Know your use cases, your SW test engineer is right in that. As soon as you know what the application does, you can identify and focus on the relevant snipets of HTML/JS (I guess so from your mention of selenium).


What helped me familiarize with the application on which I'm working, was having a local repository of the application, and i ran it locally on my machine. So when I needed to know something about validations or conditions I would just debug or look at the code. This might not be the fastest way to learn the app but eventually you will. You can also ask for some documentation of the app (requirements, UML), as that will give you a better idea of what the application does and on how to test it.

Hope that helps.


Organizations are constantly leveling up to ensure they have speed and quality going hand-in-hand while shipping new features or new products entirely. This is why automation testing in Agile has been a key to accelerating go-to-market without missing out on quality metrics. There are some tips to help you get up to speed quickly with automation tests:

  1. Analize the application pateintly: It is bery important to analyze the applocation manually before start making the automation code for the application. It is very helpful to understand the working of an application.
  2. Review test cases for the application : To understand the flow of application, review each and evry steps mentioned in test cases for the application.
  3. Communication is important: Working in a team has its prospects and consequences. A test engineer must use his team as the most significant asset at his disposal. So discuss with team regarding flow of application and also take help from developers because developers are ones who know an application inside and out.
  4. Look for the right parameters:- Judging your performance on the right parameters is as important as anything else. If you keep focusing on the wrong set of parameters, it will ultimately lead to a waste of time. The testing goals must be well-defined to proceed in the right direction. So always understand the flow of an application along data which is used for the application.
  5. Make use of the right testing tools: Irrespective of the type of testing you’re performing, having the right arsenal of the testing tool will make the job easier. Efficiently using all the tools to manage your test cycle at your disposal can be one of the most important tester skills. There are a variety of tools available that can help you explore an application in more detail, such as Postman or Wireshark.
  6. Find the right team support:- It is technically impossible for a single tester to test a large application. so co-ordinate with team members for help.

Having a strong theoretical foundation can help you achieve better results. It is the first step towards ensuring a sound performance. Tests can be identified at unit, integration, performance, and user interface levels. The test pyramid advises the testers to add more tests to the pyramid’s lower level. The tests run at the lower level are generally faster than the UI tests. This is the traditional testing pyramid you need to keep in mind while performing both manual tests and automated tests.

Software QA consulting services help in design the testing strategy, plan and estimate the testing time and costs. it helps in analyze your project and software specifics, testing strategy and plan, testing scenarios. They provide QA training sessions for your in-house project and QA teams. You may also take testing sessions from Software QA consulting services. Software QA consulting services help eliminate quality assurance process constraints and achieve higher QA maturity and efficiency.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.