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



  • 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 exp is very little in this topic).

    The project is developed in .net and .net core technologies. Please share your thoughts and experience. Thanks!



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2