Better practicing for manual testing

Question

I am working in a startup and here I am the only tester. I have a web app for testing. My first approach is as follows:

• testing the core functionality
• user experience and client experience
• Multiple browser testing
• check breadcrumb
• pagination testing
• valid and invalid data entries
• console errors & log errors
  What are the other factors should I be manually testing?
  Note: This is not a secure, performance driven, or api like application.

I want to become more of an expert in testing. I got the information from a senior tester to find the hidden bugs and also he can find more than 100 bugs within 15 minute. I want to be able to have test skills like that. How do I improve my testing skills to that level?

Answer 1

a senior tester can find more than 100 bugs within 15 minute. I want to be able to have test skills like that.

No, don't. Finding lots of bugs in short time periods probably means you will report a lot of trivial bugs. These will waste a lot of time in the whole process.

The (agile) testing manifesto suggests to focus on building the best system over breaking the system. I can break application in such ways that I can report it as a defect, but most often these are routes real users will never take. Why should I report defects users probably will never run into? Test that users will be happy with the system instead.

Just a like a doctor says when you tell him it hurts when I push here. The doctor will say then don't push there. This is the same with testing.

How do I improve my testing skills?

• Practise
• Read books, blogs, reddit, etc...
• Try to answer most questions here on SQA.SE. (research other people's problems and find a solution even if you know nothing about the topic)
• Practise
• Visit testing conferences
• Discuss on testing forums
• Did I say practise already? ;-)

Other reads:

• http://www.satisfice.com/blog/archives/958

Answer 2

I've often been the sole tester working for a startup, testing a web application and I loved it but it also required a lot of focus on what's important for a given release.

Learning to be a better tester is a very long, open-ended discussion but let me try to summarize some things that might help you now:

• Your testing strategy (how you organize your testing) will be dictated by each release and the potential failures (or risk) for that release. Each is likely to be different. For one release you might focus on performance testing, another release you might focus on functionality testing or scenario testing, etc and yet another might be about bug fixes and so you'll focus on regression testing.

• Good testing is about finding information. What is your information objective for your release? Talk to people about the release, what are we most worried about in this given release? Then search for information related to that objective.

• Test documentation should be lean. It should help you to test but not become so difficult to maintain that it takes time away from testing.

• Automation can help improve your efficiency. Not just with functional testing (regression testing) but also with creating test data, etc. Your programmers can definitely help you get comfortable with this.

In general when testing you can consider the following things:

1. Coverage. How much of something has my testing covered?
2. Activities. How did you test things? Did you use performance testing, regression testing, scenario testing, mobile testing, security, etc?
3. Risks. Why are you testing, what failures are you looking for?
4. Testers. Who does the testing? Subject Matter experts, beta users?

These 4 areas are important in helping you manage what you do and who does it. Since you are the sole tester knowing when someone else can help out, like a business person helping test certain features (as subject matter experts or as the person who requested the feature) might help free you to do more important or specific testing.

Testing is always about trade offs. We don't have time to test everything so which important things should we focus on in the time we have right now? Focus on the higher risk items first and then lesser risked items afterwards.

Answer 3

Learning correct testing terminology as well as focusing on coverage is needed. Try to expand your list of testing to cover the following, some are on your list and some not:

• Functional testing (this could be tickets or requirements or anything that defines what should exist.)
• Regression Testing (previous functionality ensuring it still functions correctly
• Boundary testing on fields (special characters, numbers, letters, length)
• Boundary testing on negative path (negative testing, or unhappy path)
• Use case testing (This is the client/user focus) - should match up with original specifications provided by the client/user (this could be tickets or requirements or anything that defines what should exist, but in a workflow like format)
• Usability testing (Including Lorem Ipsum http://generator.lorem-ipsum.info/ on text areas to ensure readability, there is 508 testing for disability, there is also color schemes, control ease of usefulness, page load times for user eye awareness(partial page load gets visual quicker if there is an issue), ease of understanding, help materials, navigation, pagination, etc...
• Data Integrity testing which involves inputs and reads of specific data as well as data manipulation within the application
• Browser testing (Chrome, IE, Firefox, Safari, etc...)
• Mobile testing (iOS, android, windows)
• Responsive UI testing (resolution changes to ensure a consistent usability despite tiny phone/web screens or not.)
• *Interface testing (depends on application specifics
• *Security testing (depends on application specifics)
• *Performance testing (Client, Server, Network)

*you indicated this wasn't necessary

There are additional types of testing that exist and many of these vary depending on your application, but here is a good start.