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 ...
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 ...
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 ...
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.
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 ...
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 ...
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 ...
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 ...
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 ...
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 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 ...
In some industries it's not feasible to test without customer data. Sometimes it's not possible to properly anonymize said data - I test software that uses the US social security number for a large number of lookups. That means that any method of anonymization must ensure that the social security number of a given person must produce the same ...
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 ...