1

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?

  • 100 bugs in 15 minutes? you will not able to enter them to bug report database. – Peter M. - stands for Monica Mar 28 '17 at 16:35
  • 100 bugs in 15 minutes sounds like an analogy. Also a bad one at that. But yeah finding them and logging them are two different things. – Chris Kenst Mar 28 '17 at 16:41
  • Frankly if you find 100 bugs a minute the application is very poor indeed... – mutt Mar 29 '17 at 15:12
0

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:

1

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.

  • 1
    +1 for "Testing is always about trade offs" alone. 1 showstopper bug found and fixed is more valuable then 100 trivial bugs reported. – Peter M. - stands for Monica Mar 28 '17 at 17:50
0

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.

  • -1 There is no standard terminology across testing (and broad disagreements when it comes to it) so learning someone else's definitions is not a great place to start. – Chris Kenst Mar 28 '17 at 16:40
  • They don't have any if you read his post...besides these are general categories you can google, not company specific If you want to be a good test engineer you need to understand industry terms, not company specific terms. It goes out the door when you swap companies and the definitions swap around depending on who is saying it, but not even knowing industry terms to talk about it wouldn't get you past the interview. – mutt Mar 28 '17 at 16:41
  • 1
    +1 to Mutt. This is just the sort of answer I would give. This answer is NOT an attempt to provide a canonical list. It provides a general list of general categories that are familiar to all of us in the software testing industry. I'd focus on the boundary, data integrity and security based on your information of what you've covered already. – Michael Durrant Mar 28 '17 at 19:46
  • To add to that, I think it is a good idea to start creating some sort of standard terminology across testing. If its never created, there will never be any standard terminology. – Renzeee Mar 29 '17 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy