Even though I consider myself more of a developer than a tester, I've realized that the best creators of perfect software of those who can build a balanced suite of automated tests with some code implemented to make them work. Although the ISTQB (International Software Testing Qualifications Board) exam has to do with all testing including just manual testing. Also, as the inventor of Triplex Testing Theory I wanted to make sure I wasn't missing anything. They have some weird vocabulary, but overall studying for this this exam can give you a great awareness of all areas of software testing without being a programming language specific tutorial on it. I don't have much time left before I go to the testing center, but my last method of studying is copying my notes here in a blog post. If you're taking the exam soon, I hope this helps!
Testing is meant to detect bugs, not prove that there are no bugs.
Testing can give confidence in the system if it finds no bugs.
Testing has the folowing objectives:
7 Testing Principles
1. Testings Shows the Presence of Defects
(but can't prove there are no bugs).
2. Exhaustive Testing is Impossible
except in trivial cases. Use the level of risk to determine how much testing to do.
3. Early Testing
Start testing as early as possible (as soon as entry criteria are met).
4. Defect Clustering: Over time the areas where the new tests are created should be proportional to where bugs are being found.
5. Pesticide Paradox: Get's it name from the fact that if you spray pesticide on plants over time it stops working and doesn't detract bugs. In software, they are saying if you write code that has no tests associated with it then your current testing suite isn't covering that, and so in that area you're not getting the benefits of testing because you're not really doing it.
6. Testing is Context Dependent
safety-critical software is tested differently from e-commerce site
7. Absence of Errors Fallacy
Key concept is that the software needs to provide real value to users. Just because there are no errors / bugs doesn't necessarily mean it will be successful.
the Test Process
Evaluating Exit Criteria
Checking test logs against exit criteria
Assessing if more tests are needed or if the exit criteria should be changed,
Write a test summary report
Testing within a lifecycle
This is what we think of as unit testing aka white-box testing aka structural testing. Think Jasmine running on karma, testing individual methods of the code in isolation.
Tests created from:
Typically, these tests check:
Goal for these is to establish confidence in the system.
Tests Created from:
Typically, these check:
Black Box Testing
Testing that doesn't look at the internals of the code- think Protractor / Selenium testing.
Describes the "what" of the system. These tests describe and check that the system or component is doing the function that it was meant to perform. To help remember this, next time you stub you toe say, "ah what the functional testing" to help connect the words functions and what.
Describes the "how" of the system. These testing include stress testing, load testing, usability testing, maintainability testing, reliability testing, portability testing
Regression Testing and Re-Testing
Regression testing is the act of running tests over and over again even though they are passing, just to make sure they are still passing (and be immediately alerted if they aren't!). Re-testing is the act of testing against after the developer fixes a bug to make sure it has been fixed.
Not building something new, adding features, or fixing bugs; just maintaining. Think running tests after updating npm dependencies.
Activities is a Formal Test Review
Types of Reviews
White-Box Testing Techniques
Refers to the fact that some testers have an intuition for what types of things frequently cause bugs and can test in ways that may find bugs that are otherwise difficult to uncover.
aka test coordinator or test manager.
tasks of test taker:
Report should include:
Introducing a New Tool
Don't allow teams to do their own things and implement whatever tools they want. Provide guidance and oversight.
Update: Welp, I took the exam, and I passed! I was a little annoyed though. I got thought I aced it, but I only got an 80%. There was a question about two-value boundary analysis that I had never heard of. Anyway, I've taking these concepts and hopefully won't forget them as I go on in the future to develop software and the Triplex Testing philosophy.
The posts on this site are written and maintained by Jim Lynch. About Jim...