17
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 ...
11
You're asking a unicorn question.
Why?
Because you've skipped over the point of all that work. It doesn't matter what proportion of different types of testing you do, it doesn't matter what your organisation is, and it doesn't matter what technologies you use, if you don't know what information your stakeholders want to discover from your testing.
That's ...
11
"Yes"
If you have an automated regression suite, you should definitely re-run it. If your organization is really on the ball, this will happen automatically along with all the unit tests and other tests as part of your continuous integration process.
If you don't have that luxury, then if you don't see a major risk, then testing only around the areas that ...
10
You should not edit the tests to pass. There are still defects in the product, and running the tests and having them fail on those points continues to provide data that the issues are not fixed.
Since the development team has accepted the bugs and scheduled (although not solidly) them to be addressed, modifying the tests to no longer report the defects ...
10
One possibility here is to build into your testing the ability to flag a failure as a "Known issue" which is then reported with each run of your automation.
I've gone into more detail in my answer to the question user246 linked - I'd recommend you check into my comments and the other responses there.
9
Extending and maintaining automated tests costs time, but if your team are slaves to updating tests you are doing it wrong. :)
One of the biggest reasons to create automated test coverage is to create a fast feedback cycle loop.
Letting the test-team fix the tests afterwards slows down this process and will always lag behind.
There is a high risk the tests ...
answered Jul 3 '14 at 12:07
Niels van Reijmersdal
25.8k2 gold badges39 silver badges92 bronze badges
8
It's not exactly clear what question you are asking, but let me take a stab.
I would deal with it by creating a bug report. In it, I would mention what you are seeing in Commit A, and Commit B. I'd mention that the combination of the two pushes performance past the prescribed limits.
From a QA point of view, it's not important at all in which Commit the "...
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 ...
7
As a general rule, retesting in the staging environment is done more as an integration/sanity test than a full retest because the QA environment will likely have different code (due to other changes that aren't being pushed to the staging environment yet).
The usual considerations are:
The staging environment is kept as close to production as possible, and ...
7
Push to make everything testable in the integration environment. The location you are testing in should mimic the production environment as closely as possible. Most payment providers should also have a testing interface, even credit-card validation has fake numbers to use.
If the devs can confirm they fixed it, use their environment, maybe even pair test ...
answered Dec 16 '15 at 15:33
Niels van Reijmersdal
25.8k2 gold badges39 silver badges92 bronze badges
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 ...
7
A good start would be to review your test cases and prioritize them. The ones that cover the most important functionality aren't always the best choice to automate but they do at least represent the place the company will want you to focus. One cannot test everything and one certainly can't automate all the things.
If your company is totally new to test ...
6
I assume that you have a suite of unit tests the developers are running which is essentially your first line regression suite.
The purpose of a functional regression test suite is to help ensure that code churn didn't destabilize existing functionality, especially across dependencies. In general, the functional regression test suite should be ran every ...
6
I'd start by looking at the answers to this question.
If automated testing is simply not possible (it happens - I live there despite my attempts to get some kind of automated regression going. Being the only tester makes the effort to automate somewhere between challenging and impossible), I'd suggest something like this:
Identify highest priority test ...
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 ...
6
There are an awful lot of variables to consider here. But here are some points all the same.
Manual Testing vs Automated Testing This point alone is probably worthy of a book and is one of the most frequent questions I see. E.g. I'm new to a project, what should I automate? Things to consider here are...
Does take a long time to execute the manual test?...
6
In my experience, when the lack of automated regression in a delivery pipeline becomes technical debt, you have exactly one option.
Treat automated regression tests as code and sprint on them the same way you sprint on new features and bug fixes.
What that comes down to is that if your team(s) didn't set this up at the start, you will have to either waste ...
6
It depends. What are the the risks?
One of the risks that come to mind are code-depencies. A fix in a piece of code could be used in a lot of location. Not just the location that the original defect occurred in. In this case you should analyze the code and decide if you need to also re-test all dependent locations.
When the application could endanger lives ...
5
Honestly, it depends.
If you're with a C# shop, it makes more sense to work with C# so you can collaborate with the developers and share code. Similarly, if you're working with a Java shop, go with Java.
A few other considerations:
The main tool for C# development is Visual Studio. While there is a free version, the licensing for it is quite limited.
...
5
I would say there is no concrete answer to this. Sure there are idealistic 'regression test everytime', but we are rarely afforded the luxury.
So it then comes down to risk management.
Is this module critical - ie worst case scenario what can it break. Ex:
Is it a change in how a profile is being saved? Is the profile being used as part of the whole ...
5
It depends.
Some factors you might choose to take into consideration:
Time - for manual regression testing, the amount of time you have available is a major factor in what you test.
Priority - ideally you'll have your tests prioritized by how critical they are to the application: I usually work this way:
Core function - The most used and most important ...
5
Starting from your first question:
Your answer did not give the interviewers any indication that you understand the technology challenges behind your automation suite. They were expecting answers that would cover possible technical solutions like:
Changing from a full browser to a headless browser stack
Optimizing code to reduce inefficiencies
Removing ...
5
Do the test cases test a functionality representing a flow? If yes, then executing only failed test cases the second times does not test the functionality properly. If the test cases are to test one after the other, then testing only failed test cases does not check if the failed test cases run along with other test cases, even if they pass the second time.
...
5
It is a common practice, but it should be handled with care.
Some things worth thinking about-
keep track of how many retries were made, it could represent a real bug and not a transient problem. For example is the first try is always failing in certain scenario.
remember that repetitions will make your results less trustworthy so treat this as a temporary ...
4
According to my view, "Scrum is the best agile approach. In scrum, each sprint produces an increment, which is a potentially releasable product. Here, each increment must satisfy all acceptance criteria and pass the different categories of tests. Regression tests are a tiresome activity, especially in an agile process, which is characterized by nonstop ...
4
As always, "it depends".
Some of the times you'd want to use a clean test database:
You're performing regression: you want to start regression from a known starting point.
You're testing setup and configuration issues
You're comparing results against some baseline. Here you're going to want to start from the exact same condition your baseline started from....
4
I'd call it Production Monitoring as well.
In my company we have "Production Engineers" performing this sort of task, not QA folks.
4
I wouldn't call it backward porting testing at all. Within A, the feature from B is brand new, making it A+2. It's a new feature in its own right. The fact that A, B, A+1 and B+1 were tested and found stable doesn't guarantee that A+(B+1) will be bug free. There isn't another name for that other than "testing".
4
There's a lot of ways you can go here - if you want to stay with manual testing you can look to improve your ability to find and report problems, or you can add load testing or functional regression testing to your skill set.
Depending on where you're based, the most effective method for you could vary - you'll want to balance between something you enjoy ...
4
You could to create a Test-specific build which stubs the input GPS data. By having a data-input interface (in code) you could have fake GPS information fed in - I'm not sure what the data is or how it will look, but whoever developed the application should be able to engineer this.
While this is going to be a build which is never to be released to ...
Only top voted, non community-wiki answers of a minimum length are eligible
