this post was submitted on 22 Jul 2023
1 points (66.7% liked)

Engineering Managers

446 readers
1 users here now

Discussion, rants, questions, and more about engineering management.

Resources:

founded 2 years ago
MODERATORS
snowe
jeff
1
Trying to get release and testing in sync (self.engineering_managers)
submitted 1 year ago by van2z to c/engineering_managers
2 comments fedilink hide all child comments
 

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.

top 1 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

Try to get each test done as early as possible. Even when a feature is not fully finished yet, parts can probably already get tested.

Other than that I would focus on test automation. Very few tests should require manual work. Both your devs and QA engineers should work on this. Devs develop unit tests and component tests, QA is more focused on integration and end-to-end (this is not a hard rule, I currently work in a team where QA only does end-to-end). Of these only end-to-end typically requires some manual testing work, but by then almost all defects have already been found, so it rarely leads to blockers.

With test automation you can run your tests all the time and get much quicker feedback. Your devs don't have to wait till Tuesday to hear if things are ok and certainly don't have to wait another day for QA to finish testing.

load more comments
view more: next ›