How to incorporate manual testing into an existing project

Question

My project is a CRUD web application written in PHP and React, with user panel and admin panel. We were just assigned a manual tester and I (as the project's Lead Developer, and a person responsible to make our software development process work) never worked with a tester, and I'm wondering how to cooperate with her most effectively.

I mean, let's say I give her a frozen copy of our system and initially she tests all of it thoroughly. We apply no new changes to her copy until she finishes (cause then her tests would no longer be up-to-date).

Then we fix some bugs she discovers, add some new features... and I'm wondering if she should test only the areas of the system where new features/bug fixes where applied or should she test all of the system all over again? Because quite often when you introduce a new feature, accidentally you break something on the very opposite side of the system...

And even if we say this is rare and we decide: Mrs Manual Tester, we did fix bug number 1 and 2, and we introduced new features A and B... We need to give her some copy of the site where this changes are applied, and which will stay closed to new changes until she finishes her test (because introducing new changes in-between of her testing process will render her tests out-of-date and confuse her). I wonder how actual teams do it... Should the the tester be skilled enough to use version control system on a local server and just check out a particular commit and stay there until the end of the test? Or should she perform it on a staging copy of the website, managed by someone else? Because it resembles the live copy the most, as it's running on the same remote server...

I wanted to do some reading on this on the internet but it seems the articles I find are too theoretical or looking at it from a different perspective.

Answer 1

As SQA, I will definitely re-test the system all over again. Yes, Regression Test is one of the stressful and energy-consuming to do as SQA. And it very important to perform Test on staging, because SQA should test in an environment that resembles Live version, and I suggest that a Manual tester have a minimum as possible technical knowledge according to the system, for better insight and more subjective persona.

From my experience, there are 2 options:

1. Focus testing on New features and automated the rest of the old features (I personally don't like this one though)

2. Evade an issue before it's happening. Before development starts, SQA creates a test scenario and test case from the new feature based on the Requirement or Team's plan, and Dev will create those new feature based on the Requirement + Test Case from SQA as well.

   • How this feature is going to works?.
   • How this feature is going to break?.
   • How this feature effect on the user?, etc.

Answer 2

To expand on Peter's statement: "Should the tester do X" or "Why can't the tester do Y" is not the way to look at things. Testers are not plug and play components any more than developers are. Some testers might have the skills to use the version control system, some might not.

A much, much better question to ask is "Where is the right place for X to happen?" Just because the tester can pull a copy of the repository to their laptop and run there doesn't mean that that's the best place to test, especially since it depends on what sort of testing she is doing. Is she doing functional testing? Load/stress testing? Localization testing? Deployment testing? These all warrant different test environments.

Also, the statement "We need to give her some copy of the site where this changes are applied, and which will stay closed to new changes until she finishes her test" is problematic, as it essentially forces you into a waterfall model. If you aren't writing new code while she's testing, what are you doing? If she isn't testing while you're writing new code, what is she doing? (The correct answer is usually something along the lines of "addressing technical debt," "writing test tools," "writing automated tests," "writing documentation," and so on.)

Also, if the tester has any experience, then you shouldn't be asking us these questions, you should be asking her these questions. If she doesn't have experience, that's a different set of questions.

Answer 3

I quite agree with Kevin, freezing your web application till the tester finishes the testing process, you'll slide into waterfall development, which is acceptable in big industry projects ( for aerospace industry, manufacture, etc.) I guess your web application is not for these purposes. Therefore, you should better consider some common practices for testing in Agile projects. As for your question,

I'm wondering if she should test only the areas of the system where new features/bug fixes where applied or should she test all of the system all over again?

You are absolutely right stating that new features may break the existing ones, which brings us to regression testing. Both developers and test engineers dislike this type of testing, as it is time-consuming and tedious. However, in Agile project regression testing can be optimized, which reduces testing time, efforts and cost.