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
"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 ...
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
31.1k3 gold badges48 silver badges115 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
31.1k3 gold badges48 silver badges115 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
• For Android
Lockito application should work for you.
It allows to emulate movement from one location to another one.
You can set the speed, the route is based on Google Maps.
• For iOS
There are at least 2 approaches:
use Xcode with GPX files
Here's good article on this. Also there is a script to generate GPX files with routes.
or add location spoofing ...
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
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 ...
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 ...
answered May 13 '19 at 14:25
Niels van Reijmersdal
31.1k3 gold badges48 silver badges115 bronze badges
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
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
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 ...
4
Why either/or? Work as a team with testers providing test ideas and expertise that the devs can code up. I would also shy away from an emphasis on GUI automation and get the devs working at a unit/system level unless they are doing this already
4
I am technically a manual tester and I just changed companies and literally had a slew of companies trying to recruit me. QA work in general is exploding as companies see how much value it offers them as a whole.
I have a feeling your issue falls into 2 categories.
A weak resume (Easily fixed)
Lots of experience with little to show for it
The question you ...
4
Here's how I would approach this kind of situation:
Unit tests - Evangelize the living daylights out of unit testing. Any kind of business logic automation should be handled by unit tests, as should any other automated tests whose goal is to check the functionality of a single unit of code. This is developer-level code, but tester guidance is essential if ...
4
The most efficient tool for testing the appearance of a website is still the human eye and brain.
That said, if you want or need to automate, image comparison is probably the least effective method because even with fuzzy logic it can generate far too many false positives. All it takes is a change in hardware (a different monitor or video card - this will ...
4
BI VALIDATOR:
BI Validator is the most comprehensive Regression, Performance and Stress Testing tool for Business Intelligence applications built using OBIEE, Cognos or Business Objects.
It is built on our patented Patented ELV Architecture.
Its easy to use Test Plans empower Business Analysts, Testers and Developers to quickly create and execute tests in ...
4
This doesn't have a single answer; it depends on the state of the code and the level you're testing at.
At a high level, regression tests are tests that you have for things that currently work in the product, and should continue to work the same way in the future. So in order to identify regression tests, you need to identify parts of the program that aren'...
4
It depends.
Every application is different. Every organization is different. Every organization and application has a different risk tolerance that determines how many of your test cases need to be part of your regression suite.
At one extreme, any test case that hasn't been deprecated by changes to the application is part of the regression test suite. ...
Only top voted, non community-wiki answers of a minimum length are eligible
