No tests in the legacy project - what to start with as tester? [duplicate]

Question

I've just joined a project, which is developed for internal use for over 10 years now.

There are no unit tests nor any other manual/automated tests designed. I'm going to be the only tester.

What should I start with, when it comes to testing in general?

There is no detailed specification or documentation.

I was thinking of going through the past bugs/tickets/stories developed and prepare test cases based on that. Also to start preparing test cases for regression tests for key functionalities. In the future, I will consider automating the regression suite with Selenium most likely (especially that my experience is very little in this topic).

The project is developed in .net and .net core technologies.

Please share your thoughts and experience.

Answer 1

In addition to reading Working Effectively with Legacy Code, I have a few recommendations from experience:

• Since there is little to no documentation, tour the software. Go through the software using it as if you were a user, noting what it does and what you can find about why it works the way it does.
• Talk to long-time users. Since this is internal software, you should be able to locate people who have been using it for a long time. They will be able to tell you more about what they expect from it.
• Talk to developers. Where you can, talk to the people who built the software. They will have information about why it's designed the way it is.
• Focus on functionality first. As internal software, there will be assumptions baked in: users will know what they are doing, so the UI does not have to be intuitive, there isn't a need for comprehensive help, appearance matters less than function, small bugs that don't interfere with function are acceptable, that kind of thing. This will help you to prioritize your testing.
• Create documentation as you work. This is something I've found immensely helpful when dealing with large, poorly documented applications. My documentation may never reach the standard expected for user-facing documentation, but it is generally enough to help developers and other testers deal with the complexities of the application. The format is up to you - choose whatever works best for the way you work, but make sure you tie it in to your test cases when you create them.
• Focus on learning the application. Test cases will come as you learn where the critical areas of the application are and how the modules fit together. If you focus on learning the application first, your test cases will be more focused on key functionality.

Answer 2

Reference material- Working Effectively with Legacy Code by Michael Feathers

The books discusses working with legacy systems, not just testing them. Some of the suggestions are using a module's Logical complexity, Dependency level and Priority to decide on what to test. It then suggests two approaches as to what to start with- easy first or hard first, both are legitimate and has their pros and cons.

I think your data driven approach is good, but when adding tests take a step back and try not to test just the bug you are looking at but the area around it, there is a good chance that like Michael Feathers says you will find the module to be highly complex or with a lot of dependencies and worth testing.

Answer 3

You can use the Heuristic Test Strategy Model as a starting point to design your approach for testing (a mindmap version can be found here).

By laying out the Project Environment, you will realize the boundaries and limitations of the project. Product Elements will help you to understand the components of the product, which you can then do risk analysis and assessment. Testing Techniques will help to define which approaches are more relevant to your testing. Quality Criteria will help you to start conversations about what is the value that the different stakeholders (including developers) expect from the project and product.

I was thinking of going through the past bugs/tickets/stories

Good, this type of documentation can show you which areas are more risky or of greater importance for the stakeholders.

developed and prepare test cases based on that. Also to start preparing test cases for regression tests for key functionalities.

Is this the best to plan your testing, especially at this early stage when you are focused on learning about the application? Of course, if you are going to automate some flow, you will have a test case, but written in a programming language - does it bring value to have ambiguous non-executable scripts (English-written test cases) at this point?

If you are looking for traceability, I would suggest reading the blog post Breaking the Test Case Addiction, by Michael Bolton.

Alternatively, you can have test charters and product coverage outlines.

Answer 4

Just a few ideas to what you said:

I was thinking of going through the past bugs/tickets/stories developed and prepare test cases based on that.

Going through some of these sources of information could be useful, but it's only something you should do in addition to actually interacting with the application. You need to learn the application, and that's best done by actually interacting with the product, not by reading a secondary source of information.

Also to start preparing test cases for regression tests for key functionalities

Why not, but you need to know what the key parts of the app are. That will take a bit to learn.

I will consider automating the regression suite with Selenium most likely.

Why jump to conclusion about a technology so early when you don't even know the app? Your tools should be chosen based on what helps you best in a given context, but you don't really know the context, not the app, yet.