I have little experience with testing and I'm being hired to work on a team where I am the only tester. I'm struggling to find the best approach for the process. Being alone should I write down a test script or not? Wouldn't it take too much time?

I have no experience in writing test scripts, could anyone help with a good reference (book, video or whatever), please?

5 Answers 5


Welcome to the site!

Your situation might be a difficult one for a couple of reasons:

  • you're new to the testing and you don't know much about the process, about the technical stuff, and about yourself in such a situation

  • you're the only one on the team who is supposed to test; I find this the biggest obstacle because you basically have nobody to ask for advice in testing; don't expect developers to contribute much in this area

  • other things just might make it worse: it's also a new company for you, new people, new product, new industry, there's no good project management, people are overworked, the project is seriously behind a schedule, the project is understaffed, etc. etc.

However, you need to start somewhere and there's no going back, so start thinking about what you can do:

  • start with your attitude - I've never been looked down upon even when I messed up when I also showed I cared about the result and about me learning whatever I messed up; if you show you're willing to work on yourself, people will give you time and space to do so; don't be an enemy with the developers, start working on the product with them, then they will help you out, give you enough information about new features, etc.

  • you can learn the product first - use the product as the user you make this product for; at the end of a day, you're testing for such people (I assume here the product is meant to be used by somebody and it's not some API or sth.)

  • learn the big picture first and details later when you already have the framework in place

  • improve your technical skills - data formats, tools, APIs, scripting/programming languages; better start slowly here, start with what you really need on your project, there'll be time to learn what you're interested in and what's not needed on the project later

  • ask questions - even if you are the only Tester there, there might be a project manager who might know the product very well, ask them questions, ask other people who know the project; however, be aware that developers might not know much about what's beyond the code; so better ask them only specific questions about some parts, that's where they can give you really good answers

  • improve your test cases - I think it's always a good idea to write at least some of them down, it makes you think about the system a bit more, it makes you focus at the task and you might come up with more good test cases; writing test cases down shouldn't take you much time away from testing, but I suppose you can find at least some time to do this; consider positive and negative test cases, pay attention to empty/null values/field, think about different combinations and states

  • read about the product if there's something to read - there might be some documentation, test cases, use cases, former bugs, etc., find some time to read some of these, it helps you learn the product and e.g. common bugs and/or areas where you can expect more problems in the future

  • don't be afraid to say what you need to do better testing - maybe you need just a little bit more time to perform some testing before the next release, try to negotiate what you need in such situations, but don't be angry if you're not given it, simply work with what you have

  • and honestly, and I hope it won't go this far, set some limits to what you're willing to do and if the project goes beyond these limits, be willing to walk away; don't share this with other people in the company, but you need to be able to say no if there's something seriously wrong with the project/company, etc.; this should be the last course of action, but you need to be prepared even for this scenario

  • if you want to read something on the Internet about testing, I recommend more concrete advice now and you can go into more philosophical topics later; so e.g. if you're testing something in e-commerce, you might find some concrete articles like 8 Important Segments Of Testing eCommerce Websites; be aware that nothing will be complete, you need to slowly piece it together from different sources

I hope I've helped a bit here. It's not as cut and dried as I might've made it look like here, you always need to consider your context and your situation.


Hopefully, although alone, you can talk to the developers, the business owner, scrummaster, etc.

At this stage you should primarily be in question mode

  • Find out what the system is supposed to do, in detail
  • Find out what the user is trying to achieve
  • Ask about different workflows
  • Determine positive and negative test cases to try
  • Ask about devices and versions that should be supported
  • Ask about previous or existing bugs
  • Ask about existing tests, especially unit tests that should exist.
  • Ask about existing documentation

Basically spend your time getting to know how the system is used by the end users.
Once you understand it well, you'll find relevant bugs easily is usually the result.

Every situation is different so there is no formulaic approach that I'd recommend


You have two advantages here,

1) Being new to the project

You will test the product as if you are a customer using the product for the first time.

If being a user with zero knowledge about the product forces you to ask so many questions and dig through documentation to do even the simplest tasks. Then there is a serious problem with the UX design.

you can write down all the user experience issues you have faced during this phase, which could include:

  1. Need for tooltips
  2. Proper color coding and error message to show user mistakes
  3. Need for more visually appealing design
  4. And so on

Don't hesitate to write down even the simplest observations. Eg: renaming back button as an edit button, providing direct links to some page. and so on.

In short, write down whatever that comes up during your Exploratory testing phase

2) Having little experience:

Even though you have very little experience, the organization has realized your potential and has given you a great opportunity. If an organization has trusted you with such responsibility, then it shows how talented you are.

So it's just the matter of tieing your shoes and believing in your self. Go there and show how to "Break the unbreakable"

The advantages you have here is :

  1. You will have more time to learn stuff
  2. No one expects you to be a test architect
  3. You can fail, and can still look smart when you figure out why that approach failed
  4. You can have something great to put in your CV
  5. You can be proud that you are going to set a quality process for that team.

Now on how to start testing:

  1. As explained, try to understand a high-level idea of the "Software under test" and start "Exploratory testing". Write down all observations.

  2. Try to understand the backend service. If they are using APIS, then see how API contract works ( contract is just a document that says when you send 'A' to the API (www/google/map) you get 'B')

  3. Now once you have done exploratory testing, and understood how API works. start automating APIs

  4. Then start with UI automation

About automation:

Automation is really simple, its about asking questions. It's about automating things you already do manually.

1) API automation:

Question: how to validate that all API response fields are correct? Ans: schema validation

Question: how to validate that request was successful? Ans: response code should be 2xx

and so on.


so decide a tool, eg: postman, and google on how to validate status code is 200. Then reuse the same logic for all other status codes

  1. UI automation:

UI automation has nothing to do with how the application looks. We are testing that the UI element's functionality is working fine.

eg: you click a button and then something should happen. So in automation, you choose a tool and then google how to click a button, then you google how to validate that the expected thing happened.

In UI automation, the main thing to learn is Page object model

in short,

  1. Decide a tool
  2. Start using it
  3. It fails
  4. Ask why it failed
  5. You learn something, and now implement it

I use 'protractor' for UI and postman for API, it was too easy to learn (once you understands promises in javascript)


We got nearly the same situation in our project. We got a couple of systems that we had to test, but just two testers for the different systems which are nearly independent of each other. So I will try to summarize the lessons which we learned at our project:

  • Exploratory testing We introduced exploratory testing and also used a tool that captured all the test cases which had been executed. At the same time, it created also test cases that were easy to adapt to our needs.
  • Mob testing We also introduced some kind of mob testing, which means that we invited our Product Owner for testing the system with us. So somehow we did some kind of pair testing techniques. This helped us much to understand the system. It is important to speak the test procedure ("So now I am clicking on this button to expect that..."). This helped us much also enables to improve the communication with the relevant stakeholders
  • Forget about test scripts We also abolished the test scripts in HP ALM. There was no time for creating test cases. So we used exploratory tools for creating test cases. This can also be done with notes where you can pin it on a board so that everyone can see what you are doing (stakeholder, product owner, developer...) Sometimes it helps since people see it and get the impression that testing is not just a click-by-click job. We also introduced Tricentis / Qasymphony for supporting this job at creating test cases. With one person it is surely hardly difficult to create hundreds of test scripts. Instead of this, I would just create a couple of test cases e.g. for Smoke test (we also had around 50 test cases)
  • Check for past bugs We also checked for past and previous bugs to try to understand the system. In this case, repetitive bugs helped us to "understand" the main issues within the system
  • Visual testing roadmap We also created a map where we tried to get an overview of the testing scenarios. As already said we had a couple of systems to test (e.g. 1. Login in a system, 2. Execute Payment 3. Check order 4. At the evening check-in, your app whether order status has been send) So made notes on a longboard somehow we made the process visible at the point from a user/customer. Afterward, we invited the stakeholders - called this day as "testing day" and it was quite interesting how Product Owners, Developers, and testers communicate :-) This was a good learning way for us!

So at the beginning somehow I wouldn't write test cases, especially when you are the one person who is doing the testing stuff. I would try to somehow first understand the testing procedure and focus on exploratory testing.

There are some good links for the beginning:

Stickyminds QA

Exploratory Testing

Angie Jones Tech

Lisa Crispin

Softwaretest Tutorials Testing


This is a very common scenario in a software testing company where sometimes a user falls into a situation having less experience in a field of work. So need not to worry. Below are some tips for the same:

  1. Firstly Understand the functionality of a product which is the most important task. .

  2. Secondly create the test cases (create one liner) if you have less time for testing.

  3. Thirdly segregate the test cases w.r.t Priority. Like P1, P2 P3...

  4. Create sanity test cases so that on every build you can confirm the basic functionality.

  5. Write Defects so that you can be able to understand the workflow of writing defects.

With this common approach slowly and slowly you will grab the testing flow.

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.