9

I think it is not a good idea because regression testing is carried out once you complete integration and sanity testing followed by system testing.

I want to write an email stating that he is wrong but I want to worded in away so I sound courteous and professional. Please advice as what to write.

6
  • 2
    Flagged to close. Your question is not clear about the situation. Even if your situation was clear, you are not asking for input on best practise in software QA, but how to write an email.
    – Graham
    Jun 27, 2017 at 13:35
  • 8
    I'm confused. Why do you think regression testing isn't part of QA? Jun 27, 2017 at 15:49
  • 4
    I'm not clear as to why you think it's a bad thing to do regression testing in QA... The sooner the better, but it's also good to have someone that's not a developer doing it as well, since they may think of scenarios that the developers may not
    – Taegost
    Jun 27, 2017 at 16:30
  • If you want to persuade your manager to run the whole test suite instead of the new regression tests added for the new bug fixes, please tell us that.
    – dcorking
    Jun 28, 2017 at 6:39
  • 1
    I hope your regression test are automated? Run them in Dev, QA environments and any other you have, before patching PROD. Jun 28, 2017 at 13:49

6 Answers 6

16

I think it is not a good idea because regression testing is carried out once you complete integration and sanity testing followed by system testing.

No, it is not necessarily a bad idea.

  • You should not consider it as a bad idea solely based on the order in which tests are carried out.

By definition:

  • Regression testing is a type of software testing which verifies that software which was previously developed and tested still performs correctly after it was changed or interfaced with other software.

As long as regression test provides business value by increasing your confidence towards software quality, it is worth doing.

Consider following scenarios:

  • Before integration test is carried out, developers put in a fix for a broken feature and want to make sure this feature is working as intended and no other features are negatively affected by this new fix; regression testing is your answer.
6
  • To Yu Zhang, the application which I am currently working on had been through a lot bug fixes, close to 100. I want to suggest to my manager that retesting would be a better option, making sure that those fixes don't reopen as another defect. Plus I want to point out that we are currently in a QA environment.
    – Jay Peris
    Jun 27, 2017 at 2:03
  • @JayPeris, what did you mean by retesting?
    – Yu Zhang
    Jun 27, 2017 at 2:05
  • 4
    @JayPeris, you want to execute re-testing to make sure all fixes are working as expected, right? The regression test suite you have does not test against all the fixes? My understanding is since you have close to 100 fixes, you want to make sure all of them have been fixed by re-testing them. It serves the same purpose as regression testing, no?
    – Yu Zhang
    Jun 27, 2017 at 5:08
  • 1
    When you say a QA environment, what do you mean? Regression testing is part of QA. Jun 27, 2017 at 15:50
  • 3
    "a lot bug fixes, close to 100" - That's either a very small project or a very clean one. Jun 28, 2017 at 11:02
8

My Advice:

Do not communicate your disagreement by email

Schedule a time to meet with your manager and have the conversation with them.

Emails do not work well for this sort of communication as it is not clear what the all important 'tone' is and it is also one-way at a time which does not work very well for difficult conversations.

The manager may also expect the conversation to be mostly about learning the reasons and rationale why he/she made a given decision as opposed to whether the decision itself is correct or not. After all you should expect your manager to use their wisdom and experience to guide you. If the discussion and your questions and any additional information you bring to the conversation reveal an incorrect decision, you can uncover that in the process of that discussion together.

7

Very well put by Yu Zhang.

I just want to add my two cents to cover another aspect of it.

Even if we think that the manager's suggestion is incorrect. Before reacting, it is always good to spend some time to think about the suggestion and come up with all the benefits and drawbacks of following the instruction. Apart from that, we should also discuss our thoughts with friends and colleagues to get their view about the instruction (which you have rightly done by discussing on this forum).

In case, even if implementing the suggestion won't be fruitful then we need to be careful about the words that we choose to respond to the manager (or be it anyone). At the end of the day, we need to make sure that everyone is motivated. If our reply demoralizes someone, then that is not good since manager can also make a mistake.

My way: Go for one to one meeting instead of email

My way to deal with such situations is; to have a one to one (in person) discussion with the Manager. I will generally start sharing my thought about the suggestion in a way as if I want to acquire more knowledge about it.

How do I always get positive outcome in such scenarios?

First of all, be courteous when starting such a conversation and don't start as if you are going to discuss a very big issue. Just start as if this is another thing that you want to discuss. I have always got a positive outcome in such a conversation. By positive outcome I mean, sometimes my manager put light on the aspects that I was missing and sometimes I talked about some aspects that he had missed. So, either I convinced him or got convinced.

How can such conversation go in the wrong direction?

From my experience of the last 10-12 years, I feel that such issues are easier to resolve if our intent is to get the perspective of another person or share our perspective. Such an issue takes a bad shape when the conversation revolves around "who is wrong?". Then start the ego issues and so on.

6

You sound professional by outlining specific issues you foresee if the testing is carried out as your manager suggests. I could imagine several such issues:

  • regression tests require significant effort to be executed, and this effort will be wasted by running them prior to complete integration
  • regression tests were designed for a complete software, and running it on a "work in progress" version would trigger too many false positives
  • you don't have any regression tests yet, and designing these now would divert the team from tasks which in your opinion should have higher priority

There may be other reasons which I couldn't imagine on the spot but these may be valid nevertheless. If you believe they are serious enough, don't hesitate to communicate them to your manager.

As such, there's nothing wrong with regression testing of incomplete software or individual software modules. If the only counter-argument you have is that such tests are "non-orthodox", or that they shouldn't be called "regression tests", I believe you should reconsider your position.

4

As per me directly saying No for regression on QA environment is not a good idea. You should ask him/her questions like:

  1. why he wants you to do the regression on QA environment specifically?
  2. What he actually means by regression testing?
  3. Did Client or end user found bugs?

Answers to this questions will help you to read your manager's mind and based on that you can do healthy discussion and can put your points that, it is not advisable to do the regression on the QA Environment.

Instead of arguing you can give some proofs which say it's not worth to execute regression suite on the QA Environment.

2

As your product matures, the regression test suite will take more and more time to run, but only seldom report failures, so moving it out of the normal development cycle and into automated integration tests makes a lot of sense.

The responsibility for test automation is with the test team, so the regression tests should be handed over to them, after the developer has verified that the bug is gone.

It does not make sense to run a hours-long test suite of tests verifying that all long-closed bugs remain gone before each commit. Rather, it is sufficient to run the tests associated with the feature group that was modified before commit, and all other tests over night. The one or two times in a year that a nightly build catches a regression (which means that developers should base the next day's work on top of the previous build) cause negligible extra effort compared to extra time spent on each commit.

Not the answer you're looking for? Browse other questions tagged or ask your own question.