this post was submitted on 22 Jul 2023
17 points (94.7% liked)

Experienced Devs

3979 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 1 year ago
MODERATORS
 

cross-posted from: https://programming.dev/post/864349

I have spent some time trying to simplify the release process. For a variety of reasons, we can only release on Thursdays. The code is "frozen" on Tuesday before it can be released on Thursday. But we sometimes squeeze in a quick fix on Wednesday as well.

The question, is when should QA test the code?

Here is what I have seen happen:

  1. Dev writes code and sends it to QA.
  2. QA finds problems, sends it back to the Dev.
  3. Dev fixes and sends it back to QA.

I have seen a Dev fix their code on Tuesday, and then QA comes back on Wednesday with problems, when the code should have been frozen anyway.

I am looking, what should be the best solution here.

We have several problems going on at once:

  1. Developers test on the same server as QA tests. I am working to switch developers to a separate Dev server, but it is a long work in progress.
  2. We don't have an easy way to revert code back from the QA server. It is easier to build revisions than revert changes. We can try to revert code more, but it will require a culture change.
  3. QA don't really have a schedule when they are supposed to do functional testing vs regression testing.

I don't know what is the best way to proceed forward. Thus far, I haven't thought too much about the QA because I was focused more on getting releases out. Now that releasing is more simplified, that we can potentially do weekly releases, I am trying to see how we should proceed with the testing process.

you are viewing a single comment's thread
view the rest of the comments
[–] kersplort 0 points 1 year ago

All of these things are less serious problems if things move faster. QA review of the master branch is the only thing you're doing that has to be long running and synchronous.

For your acknowledged problems:

  1. This is huge, and should be a focus for you.
  2. This isn't actually a big deal. Outside of fixing bad prod deploys, reversion causes more problems than it solves. If you get the devs out of QA, the need for this will decrease.
  3. If you freeze the code on tuesday and release on thursday, that sounds like a schedule!

It sounds like the QA department is overwhelmed. You need more test automation in order get the turnaround for regression testing down. Many end to end test tools have recording functions - a senior QA or engineer in test could quickly get simple but brittle automation in place.

Devs need to understand that QA stopping the line is a last resort, not a personal safety net. More unit and integration testing will keep more of the work on the devs until it actually is ready.

What does your source control and CICD situation look like?