Company pays me to test good and not be careless.
You are asking this question here - you are not careless, you care about the job you do and the things you can improve on.
Don't take it personally and be professional
The point of finding bugs is not to blame anyone, but to enhance the product's quality. If your manager is blaming you personally, this is ...
There will always be smart technical people who do not like to code. There will always be ways of taking advantage of their talents.
I'm a coder. And I love my manual tester. She sees the world differently than I do and that's exactly what I need. What I hate are manual test scripts that pile up without any automation behind them.
The solution isn't to ...
Please do not resign.
As alecxe has said in his post, Perfect Software is a myth.
I would like to add, the difference between a tester and a developer is: It is very difficult to see how much a tester has contributed.
When a developer is given a task to develop a feature, this developer
will produce a tangible result, e.g. a clickable button.
But when a ...
They cannot be 100% sure of a bug free system. They can increase their confidence that the system is bug-free by use of static analysis and testing. Some people advocate bebugging as a way of estimating how many bugs remain in a system. There are at least two forms of static analysis.
If the system goes wrong then it goes wrong. There are assorted methods ...
NASA's Software Assurance Technology Center at Goddard once did a test to see how few defects they could get in some code for the shuttle. After a truly rigorous and vastly, vastly expensive process, with multiple levels of review, using very small functions to minimize the risk in each, they managed to get it down to 1 defect per 10,000 lines of code (might'...
Testing no longer means testing
Confused? We can imagine! The purpose of testing used to be fairly
clear–“Testing is the process of executing a program with the intent
of finding errors”. This changes when adopting agile and
I think the testing manifesto has it at the right end. Focus on preventing defects over ...
I'd like to address the reporting aspect of the question. You say...
I just keep on writing excellent test cases and executing them, but then I don't have anything to show to the management. Sometimes it makes me think that I am not providing any value to the product
Even in the perfect world where the software leaves the developers' hands 100% bug free ...
It is very admirable for you to consider a tester's role from this perspective.
The hard cold fact:
No one is happy when there is a bug found in their code. Imagine yourself as a developer, you have done coding, you have done unit testing and you feel pretty good when you check in your code. How would you feel when someone shows up shortly before code ...
Yes, while rather crude and possibly not the most graceful of test cases, such 'abusive' test cases are an important tool in stepping off 'happy path' thinking and testing.
Effectively a test like this is a crude load/response test.
While in theory it shouldn't happen in the real world environment, the fact that a bug was discovered with such abusive ...
The traditional definitions would be something like this:
A test suite is a collection of test cases related to the same test work. You might have a suite for regression, one for build verification tests, a suite that is specific for a component, and so on.
A test plan is generally a document which describes testing approach and methodologies being used for ...
If I was being interviewed and was asked this question, first of all I would start off by trying to quench my curiosity.
How much time do I have?
What type of a toaster is it?
How much power limit does it operate on as per the vendor?
Does the vendor provide any user manual or claims documentation?
How does it work? Is it timer based or manual toaster?
As the other answers have said, do not blame yourself. Nobody can test any piece of software completely, any more than anyone can write completely bug-free software. It's too complex.
I'm going to quote an example from an article I wrote over at the Ministry of Testing Dojo: Ten Misconceptions About Software Testing. The quote is from a section explaining ...
That's my estimate. Some say 6750, others 500, others yet wouldn't go over one million steps per case.
Jokes aside, there is no fixed number nor there is someone who would set the limit. It is pretty vague anyway what is a single step case.
For example, you could write a test case in this way:
Login to the app
Add 2 items to cart
Confirm 2 items are ...
All non-trivial software has bugs. Risk is part of life. It is foolhardy to attempt to remove all possible risk, because in the process, you introduce the risk that you will accomplish nothing.
Even if your algorithm and your implementation are perfect, your software does not live in a vaccuum: it depends on compilers, interpreters, libraries, operating ...
First of all, "no technical solution" isn't exactly correct. From my understanding, the technical solution is in fact very simple; either:
improve the Excel macro to provide better validations
or, make the import function of your application more robust to prevent errors (abort the import) and to clearly signal the problem values to the user.
Yes and No
More often than not, an inverted pyramid (ice cream cone) is an anti-pattern, but there are circumstances where it is not. Your example of needing to rebuild an API in a different language is one such example.
Some other circumstances where you might want to invert the pyramid include:
You have an integration to a third party API. Your lowest ...
Test automation can NEVER replace manual testing.
One classic argument is test automation can never catch random bugs that can be caught via manual exploratory testing.
I have had two colleagues in the past who did not know any coding skills and hated coding, but they were extremely good manual testers, were able to catch bugs no one else could.
A requirement is typically a general statement, whereas a use case is typically a specific statement implied or derived from the requirement. A requirement may map to multiple use cases. A scenario might be a set of background assumptions that put a use case in context, or it might be grouping of use cases.
Here is a contrived example. The requirement is ...
For testers to become more valuable and helpful for the development team...
Focus on helping developers earlier in the process
Focus on adding value much earlier in the process. Focus on working with developers before and as the code is being written, not after it has been deployed in a testing/staging environment. This will help change your role from a ...
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 ...
Great Question Niels.
Given that it will depend on the given situation I would consider approaching this as a data gathering exercise. I would investigate what is the normal distribution from many repeated runs. If 99% of the time it remains correct after 1 minute (i.e. after
1 minute doesn't then change again) and the business considers a 1% failure (and ...
There is definitely a focus on test automation, not automated testing—simply because the latter is hard to do. I think this is related to the testing vs. checking debate (started by James Bach and Michael Bolton):
Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: ...
A key strategy for me is to convince the business of what needs to be tested where, otherwise... they'll end up directing testing everything through the UI... So the two key main points I am making to my business are the need for test automation that performs well in terms of two key factors:
Success in both speed and reliability for ...
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest ...
my colleagues suggest me to learn and create a fully functional -
generic framework which any team can use?
I suggest you don't. Your coworkers suggest you to start over-engineering. It is fine to experiment.
Automate a test, automate another one. Maybe a reusable abstraction emerges. Maybe this becomes a reusable framework. Practise the YAGNI (You aren'...
Welcome to SQA, Ana. I see at least two questions:
Does it make sense to distinguish between focused tests and workflow tests? Yes, it does. A focused test concentrates on a particular feature, including things like edge conditions. It attempts to answer the question, "Does this feature work in all circumstances?" A workflow test verifies that the ...
Verify name is mandatory or not
Enter the value as blank spaces on mandatory fields and click on Save button
Enter the value as Special Character & Numbers on mandatory field and click on Save button (a. 12345, b. /--+-,
Check Data type(s) for required field
Enter value as "a to Z" and check the character length and click on ...
Can a Manual Tester survive in software industry without learning Automation?
Survive - Yes, but be valuable and desirable on a job market in the long run - No.
Let me expand on this thought.
You can, of course, grow as a professional doing manual testing only exploring new techniques and methodologies, testing different products in various industries ...
As Michael said, there are a lot of advantages to the test team using the same language for their automated tests as the application language. About the only point Michael missed is that when both application and test automation use the same language, developers can help testers with automation code, allowing things like tester-developer pair programming ...
As others said, use Pageobject and other best practices. Few links:
PageObject explained - by Martin Fowler, language-independent
Selenium Best practices - with short summary, for Java
Use PageObjects pattern
Be fluent with
return this, varargs, generics,
reuse your model and jodatime
Be robust and portable
Prefered selector order : id > ...