Knowing basics of JS will let you:
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" ...
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 ...
Each company has its own process for handling customer-reported defects. The one I'm most familiar with is more or less as follows:
Customer support person attempts to reproduce defect and updates the report with any extra information
Customer support or product owner searches defect management tool to determine whether or not the defect has been ...
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 ...
You will never ever cover all of the possible test cases.
and found quite a few defects in the code. Most of them got fixed.
Were any of the bugs related to these. Did you point out the possible consequences of the ones that were not fixed?
I did my analysis and gave important information to the stakeholders.
Did anyone read it? Did you point out ...
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 ...
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. ...
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 ...
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.
To answer your questions:
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 ...
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 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 ...
Wonder why you want to present this to management? What is your goal here, what do you hope to achieve. Do you want to show them they have unknown quality issues?
Normaly I would expect the product to have either an issue tracker or a backlog. Just put the issues on the list, discuss it with the business owners and let them prioritize. Together consider the ...
So I can also give you an example in our situation. We had not exactly the same issue, but at production we also found a lot of issues and we were facing some troubles in the past. There were some scenarios how we improved the quality
1. All bugs found, create test cases for it (at least for the cricital ones): For bugs which we founded we created test ...
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 ...
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 ...
It depends on the company to company and it's organizational work culture.
In my current and previous companies,
When a end user reports a bug first it goes/assigned it the QA team.
Then the QA team tries to replicate it in lower/Test environments (sandboxes).
If it's a valid issue then QA team documents the exact steps to reproduce it and after that it get'...
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 ...
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 ...
Corner Case Testing:
When the system breaks only for a specific valid input
Imagine a function getcar() that that takes a number and all numbers from 1-5 are valid inputs:
getcar(wheel=?) function works with all numbers but fails for getcar(wheel=3)
Edge Case Testing:
Here we check that the system handles extreme values of valid limits.