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 ...
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 (...
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 ...
If the image is being generated by some process, you should be able to automate just about the entire process right up until generating the image with any data set you want.
Rather than testing every single data set being passed into whatever function generates the image, test the image generation the way you would approach testing almost any other unit: ...
Think it this way:
Test case = is a set of conditions under which a tester will determine
whether an feature can function as expected.
Test specifications = well defined conditions that will define test
Test procedure = how a test is carried out, what to do for step 1,
step 2 and etc
Test design = how a test is conceived from ...
While studying for the ISTQB exam, I have shrinking down to a more summarised text to help me understand and remember the topics at the exam.
Here's a bit of what I have shared in my blog last year.
Before all that you will need a TEST CONDITION.
What is a test condition?
A: An item or event of a component or system that could be verified by one or more ...
"More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded..." - Boris Beizer, Software Testing Techniques 2nd ed.
D. Gelperin and B. Hetzel also first suggested the idea of "Test, then code" in 1987.
There are too many factors to be taken into account before selecting the correct testing sequence and sometime not all of the tests you have listed are really needed.
Anyhow, let's imagine the worst case when your QA team receives a new build ready to be tested, I would follow the sequence below:
Sanity testing (to be skipped when the ...
We took 0 and 101 to test for INVALID data scenario.
We took 1 and 100 to test whether = part of <= and >= is working or not.
We took 2 and 99 to test whether VALID values are also working in(best case scenario) or not. You can treat this as a positive test case.
So three test cases scenario would be there:
1) for INVALID values.
2) for exact ...
We faced this during recent hiring and it took 6 months. We finally learned:
Test their automated test writing skills
i.e. the thing we want them to do on a daily basis!
Yes we started off with the puzzles and algorithm questions provided by our development group. However these consistently turned out to be poor predictors for the good people we wanted ...
I'd suggest starting with looking at the answers to these questions:
How to become a more Creative Software Tester?
How can a Software Tester use "Out of the Box" thinking approach to find more bugs?
There are a lot of useful suggestions there.
Some other things that can help:
Practice pattern recognition:
Take a large data dump or log ...
I would like to make a strong case for automated testing through the following points:
Coverage. Automated tests are much faster and give much better test coverage. What's not covered is potentially wrong.
Reproducibility. Because timing and inputs are almost the same in different test runs the results are more consistent than with manual tests. Errors ...
Is there anything wrong with my flowchart?
Yes and no. It is correct functionally: it describes exactly what the code is supposed to do. However, in code, Display_messageZ is called in two places (instead of one, as in your chart).
Why is my answer incorrect?
Because you follow the chart instead of the code, you miss the second call to Display_messageZ to ...
In your example, yes, it might be overkill if you are performing white-box testing. However, if you couldn't read or didn't have access to the code (i.e. black-box testing), these tests would be very useful to make sure, for example, that the implementation didn't look like:
if (x == 1 or x == 100):
First of all, it is understandable that a former developer might approach testing in terms of individually testable layers or sub-components. However, as a tester, if you do nothing else, you must verify that the finished product behaves correctly when exercised using whatever interfaces the end-user will use. Everything else is secondary to that -- ...
There's a lot of ways you can go here - if you want to stay with manual testing you can look to improve your ability to find and report problems, or you can add load testing or functional regression testing to your skill set.
Depending on where you're based, the most effective method for you could vary - you'll want to balance between something you enjoy ...
I would strongly recommend that you consider signing up your team for the Association for Software Testing's excellent BBST series. It's a great introduction to the foundational concepts they'll need to understand why we test, but will also challenge them to improve their skills at explaining and analysing their ideas about testing and expose them to ...
I once tested a Windows client UI by randomly banging on the keyboard while my coworker randomly moved and clicked the mouse. I found bugs that way, and I could reproduce them, but (at least initially) I couldn't tell you the exact set of keystrokes and mouse clicks that triggered the problem. That is monkey testing.
Exploratory testing is testing ...
Know your product.
Do you have a lot of regression problems? Do regression first.
Do you have frequent technical break-ups? Do smoke testing first.
It's the opposite : your application is very stable, so it's important to focus on the new features : Do Functional testing first.
The rationale is to go for the low-hanging fruit, which is different on each ...
Some prevention activities that our QAers provide are
Providing test data early enough so that it can be used during Unit Testing
We'd really like to do more. But in our shop, the schedules and workload dictate otherwise.
According to ISTQB (v2.3) "Standard glossary of terms used in Software Testing":
Test approach: The implementation of the test strategy for a specific project. It typically includes the decisions made that follow
based on the (test) project’s goal and the risk ATM assessment carried
out, starting points regarding the test process, the test design
A thumbnail definition I've used on occasion is "unit tests and good development practice make sure it's built right. QA/Test also tries to make sure we're building the right 'it'" - that is, tester focus tends to be more broad-based and with an eye towards the presumed end user.
Some of the resources I'd recommend are active here: Joe Strazzere (All Things ...
Should I create some linkage in my documentation so that the same
inputs are avoided across different scripts?
Yes, you should create the same to avoid repetition of input data and expected results. Doing this your number of test cases will get reduced to required value, this will save you execution time and test case maintenance effort.
Should I avoid ...
With manual testing you also need to write scripts. If you do not make your testing efforts reproducible you will keep reinventing the wheel and maybe even forget functionality which is not obvious.
The best automated test tools are open-source and free of costs. I would really challenge if you want to buy-in to a commercial proprietary testing tool, ...
Neither is better than the other. They aren't competing, really, but simply different approaches for a problem. Let's use an analogy.
Feet vs Car
Manual Testing (Feet)
Think of manual testing like walking or running. You need to walk places. I mean, even if just to get from your bed to your bathroom in the morning, you need to walk. With walking, it's ...
Here is how I have seen this implemented before:
The consumer B produces a "B to A consumer contract file" that contains example requests and responses that it expects from A. B will contain a consumer test that produces this file and checks that B behaves correctly when it receives these expected responses from A.
Each time B builds, it publishes the ...
You should use the order that the company expects in the dropdown
That should be the order that makes most sense to your users based on their context
There is no 'best' way or simple standard other than what is most suitable for your situation based on the business requirements.
The most suitable approach will depend on many factors.
Context will also ...
This is a good question, from my experience you should be breaking down the technical skills you expect the candidate to master into 3-5 essential must have skills. For example:
Knowledge in scripting/programming language, such as
Knowledge in relational database/no SQL, such as Oracle/MongoDB/Hadoop/SQL
Knowledge in testing ...
Ok, I edited this answer based on your clarified question. (It makes sense now.)
It is important to treat automation as a tool rather than a "tester". A major fallacy in automation is to treat each of the test cases as pass/fail tests. Instead, it is better to treat them as "trip wires" that simply indicate additional attention should be paid to the test ...
The problem may not be with your observation skills. It may be that you are expecting too much from them. Inattentional blindness (as described in this article by one of the original researchers - and yes, this is about the invisible gorilla experiment, if you've seen that famous video).
The human brain can only absorb so much. That focus (ability to block ...