20
Following the Skeptics SE guidelines I would expect a question like yours to be accompanied by sources, otherwise it's just a collection of anecdotes.
To answer your question my own experience and knowledge is the opposite, more and more companies are moving to Modern Testing or some forms of Combined Engineering where testing and quality are owned by the ...
17
What I observe is that it is hard to hire good programmers who specialize in automation and the particular set of skills needed for it.
The result is that you end up with either manual testers or full stack devs doing testing. All the other varieties of 'other people writing test automation' (as I term it), lead to a lot of communication and goal issues.
...
16
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 ...
10
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 ...
9
I can give an example from our company which is nearly the same what you desribed. Let me shortly explain how we worked. We got two departments, one was the IT-department - which had testers (manual and automated testers) and we as business department had also testers (more epxloratory testing and manual testers). Most of our work was done twice, but ...
7
The biggest problem with failure is not learning from it
Management should will be grateful if you
Acknowledge the failures and put together a plan to address them and future occurances
Did they say all those specific words:
You are careless?
You are not worthy of asking?
You are risky?
Or are those words you are using, based on your - very valid ...
6
I am just rearranging the order of your questions so that this could be answered more clearly:
Is this trend specific to companies?
The answer would be more product-specific, and test level-specific than the organization.
Let's see automation approaches in different test levels:
System testing:
Critical applications
Consider critical banking ...
6
I can think of several issues:
Test automation fails if the test automation engineers are too far separated from the software engineers.
In a perfect world, fully automated tests allow continuous integration and deployment. That means almost any software change requires a test change to make the tests run through if the change affects APIs, or service ...
5
What you see is actually a not uncommon pattern and not limited to software testing.
Many companies advertise the job that they would like to have, not the one they actually do. I am sure that in the heads of the managers there, most testing is automated and a few edge cases require manual testing. They may or may not understand that this is their vision, ...
4
This might be a tricky situation, especially if you work with people who have never worked with testers, or have not much experience in software developement in general.
I think there are a few important points you and your colleagues need to realise:
You will never cover all the possible test cases. That's not even not job, because then, you'd be ...
3
However exhaustive testing is not possible. we as a team consider following facts which might affect the coverage of Testing:
Effective Communication with Business Analysts: I believe testers should have proper understanding of what to test. Testers should be explained what problem clients are facing and what could be all possible solutions and why this ...
3
All other comments have explained the situation and solutions pretty comprehensively, but i just want to add few thoughts:
and found quite a few defects in the code. Most of them got fixed.
Here you have to ask yourself some questions,
Where these bugs critical in nature ?
Does it require hard effort to identify these bugs?
As discussed in many threads,...
3
Quite interesting topic and although this question has been raised two years ago it is still a current topic! Hence I would like to share our experience / thoughts.
Preparation from our side as business department:
We used a web application
Before starting we explained the product
We encouraged the applicant to speak all his steps "loudly" so that we ...
2
I think most companies are late adopters when it comes to test automation practises. They understand they need test-automation to become more nimble, but they lack the guts to stop current development for three months and turn the ship around.
So most companies that make software that could hire you have a product with atleast a 2-3 year old codebase. Small ...
2
I think this is because Automation is still relatively new, and a buzzword.
Most organizations love the sound of it, and the 'immediate return' it could promise.
But because it's so new, they just don't know what it entails to set it up and do it right, nor any infrastructure for it; so after floundering for a bit, fall right back into manual testing.
2
I think this is a much better idea than asking questions such as "Where do you see yourself in 5 years?" etc. :)
Let me share a few points I find important:
Regarding the application under test. I'd personally choose one I know and one where at least some bugs could be found. That's because I'd like to see the candidate reporting issues or at least talking ...
2
This is a very interesting topic and I have conducted a few interviews similar to this and here is my feedback based on the interviews:
You can evaluate candidate's ability to find out bugs within the given timeline.
You can evaluate the candidate's ability to focuses on functional or non-functional issues first.
You can judge the testing approach of the ...
2
Your testing is good. You are considering different possibilities and conducting experiments to see what happens. That is great.
I would continue that process. Here are some thoughts for you to try out. They are not answers you can copy and paste (which, as you indicate is good), they are ideas for your to try out yourself. Good luck!
Try special ...
2
An example comes to mind:
"Change request" - user wants additional changes that are not in the original scope of the app, this also includes any additional requests from the user
1
https://www.psav.com/bandwidth-calculator
Use the above site to calculate the bandwidth required for 500 requests. Say u kept 500 concurrent users with usage high , then u need roughly 70mb/s network bandwidth.
If you are interacting with your API using internet ,you can send max of 4mb/s. The remaining packets will get que and you will feel like your ...
1
Depends on the goal of the document. This could differ per industry/company. Maybe a better question would be : "Examples of post deployment documentation".
Personally I see no need for any post deployment documentation. Most documentation can be produced before deployment, for example the changelog which informs users what changes where deployed.
...
1
A few things can be considered here:
Creating some kind of coverage matrix or document in which you identify what you will and will not be covering in your test cases. This can then be agreed on with you customer ahead of testing. This could also prevent/safeguard you from missing any (big) functionalities as you customer would highlight anything they ...
1
EDIT: This answer is better suited for measuring automated test suites. But I will keep it here anyways as the question has the automated-testing tag
One concept which blew my mind when I heard about it is Mutation Testing:
Mutation testing involves modifying a program in small ways. Each mutated version is called a mutant and tests detect and reject ...
1
I realize that my answer is pretty late, but, I do have another solution that has worked well for me in the past. When you start your browser, or other application, start it from file manager (option is not available in start menu). Press shift + left click and select Run As Different user. You can do this for each of the users (although I myself have ...
Only top voted, non community-wiki answers of a minimum length are eligible
