Imagine you are working in environment where new features come out rapidly and builds happen every few hours. Every new feature has a potential to break something existing in some part of the system.
You don't have time to manually do full regression testing every day, so it's a smart idea to invest in an automation suite that will perform regression ...
Such open-ended questions are trying to uncover if you have real-life experience tracking down misunderstanding and unsaid assumptions (which are always the source of the biggest problems in QA), if you have experience of quickly learning about new problem area.
They are not concerned about right and wrong answers. If interviewer has a preconceived "right" ...
Knowing basics of JS will let you:
I think the most appropriate answer to this is IT DEPENDS.
With manual testing you can always improvise and adjust your tests on run time and look into unexpected conditions and handle them well.
While in automation testing the script will do only what they are programmed to do. They will not handle unexpected conditions or any change in the AUT (...
Good and Interesting question.
Here are some to make the tester's job easier:
Developers should perform basic testing before giving the product to the tester.
Include QA from the beginning of the project, not when the product is ready to test.
Work as a Team, not as two different departments [Developer & QA]
As the developer, never ask the QA to ...
As others have said: code review.
It is not uncommon for code like assert true == true to be used as a placeholder during test automation development (I personally would use assert true == false or assert fail or similar as my placeholder so my code could not pass until I was ready to write the correct assert, and so there was no chance I would forget the ...
When a defect happens, you want to analyse how it happend. So you can decide if you can prevent similar issues in the future. I would use a simple root-cause analysis for that. Maybe you want to involve other stakeholders like users, developers, managers, etc...
I think it is part of the QA role to make sure preventive actions happen, as we
are a force ...
Depends on your definition of testing, anonymized data is widely used by Microsoft and others for monitoring and testing in production, it's the basis for A/B testing or monitoring for example.
In Europe the GDPR does not allow usage of private data, but the GDPR does not apply to anonymised information and anonymised data can be used without consent. ...
All engineers (application and automation) test algorithms by providing known inputs and having knowledge of the expected output in order to perform verifications.
The verification values can be found by manual calculations and/or different algorithm(s).
If the algorithm and manual calculation approach are not known another approach is BDD (Behaviour-Driven ...
Treat them as equals.
I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.
One of the reasons would be to write end-to-end automated tests using Protractor.
Additionally, knowledge of a programming language used in a project may be ...
I would start by collecting cleaning up the data - don't pick 50 random bugs, but start by classifying them, manually or semi-automatically, maybe using keywords or information from the bug's logs - bug's age, environment, software module, etc. A bug can end up belonging to more than one category.
Move on and look for correlations in the data. Again this ...
Just a few quick ones off the top of my head:
Run the code they've completed at least once on their machine before marking it as 'Done'.
Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written
Encourage QA to participate in sprint planning/grooming, design ...
I've worked in both roles for a while and my recommendation is:
Pair (before coding when possible) on test plans
See QA as an asset that is protecting you and customers from the mistakes we all make
Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding
Don't assume that they can pass ...
I think their job should be to find significant issues that will affect the user and the business
I think that 'doing his job' means a lot more than clicking on every item and entering bad information in every field. It should be, within the context of the application, the industry, the user, the task, that there is a significant issue that affects the ...
To answer your questions:
Whenever I get the "how do you test x' questions I fall back to the tried and true:
How should it initially appear - smoke test
How should it work - happy path
How should it fail - sad paths. This is usually most of the response to the interview question
How should optional components work correctly - happy optional path
How should optional components fail ...
I disagree with other answers.
There is a joke
A code tester walks into a bar. Orders a beer. Orders ten beers. Orders 2.15 billion beers. Orders -1 beers. Orders a nothing. Orders a cat. Tries to leave without paying.
Basically, tester's main job is to break things. It is job of coming up with edge cases that no one came up with before. Anyone can ...
The short version - It depends
The long version
Depending on the type of testing you are doing, some form of automation may be the best choice, it may be a helpful way to get yourself set up to perform the manual tests, or it may be worse than not testing at all. Or anywhere in between these extremes.
Computers are very good at doing something exactly ...
30 Good Practices to improve Exploratory Testing
Use a bug tracking system
Use boundary testing of values
Consider using testing personas
Use happy, sad and optional paths
Become skilled at reading server logs
Learn about usability and accessibility
Learn to use emulators and simulators
Learn more about the customers needs
Be present in business process ...
I am in for this idea. This can be a part of regular testing. But whether it will have a positive impact on productivity; is largely dependent on the way you implement this idea.
Definitely, there are positive aspects of gamification which you have talked about above.
I just want to focus on implementation part of it. Because we have to take care of the ...
I wouldn't say it is common to use real data in testing, although the customer might provide a subset of "real" data in order to facilitate the process.
Apart from the privacy and business issues, there are also the legal ones, e.g. General Data Protection Regulation (GDPR) has been enforced since 25 May 2018 in Europe (but I think every company dealing ...
I will answer this question with Agile iterations in mind. (An iteration could be a full Sprint or a single-user-story-cycle if you do Kanban or swarming.)
The QA department is understaffed when:
Not every cross-functional Agile team has a someone with QA knowledge
The ratio defects versus released features is getting out of control
Test automation is not ...
Ask more questions.
Strictly speaking, to have higher quality in product, have
However, I would determine the maturity of your development processes.
Ask questions such as:
How closely are developers and testers together to share understanding?
How do you do three amigos when a change arises?
What shape is ...
This is a simple point, but very effective:
Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect.
It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.
In a world of continuous deployment test automation is becoming the most important form of testing.
The biggest problem with test automation is how do the engineers know they have covered all the important execution paths. There exists code coverage, but that just finds untested code, it is not a quality target.
If you combine code coverage with mutation ...
Such domains are often regulated
In some such industries there are external regulations that require certain processes to be in place, not only for testing but also for the rest of the development cycle. I work in the medical device industry, which in the U.S. is regulated by the FDA. The FDA has three "classes" of medical device based on the level of risk: ...
Oh boy! There is an interesting one.
Well apart from checking all the technical skills and blah blah, I always make sure to ask or observe two things about a candidate I am about to interview. And in my opinion someone who lacks this or are weaker in these skills, blows up his/her interview or rather, reduce their chances of getting hired.
As a tester, ...
I have been telling them that 100% tested and bug free product is a
It might be the way you are telling it. Probably it is true, but having an attitude "it is not my problem" is not the right one. As a business I would like to see someone who cares.
Your reaction should be something like: "Damn! Let me figure out how we can prevent this the next ...