​"Alone we can do so little; together we can do so much." - Helen Keller

Testing algorithms is slowly becoming a community where software testers learn together to make a difference. We challenge the conventional believes and practices of software testing to make our work easier, yet effective. 

With the worldwide popularity of Agile methodology, the lines between a business analyst, a developer and a tester are fading day by day. At this juncture, it is essential to have perspectives of each other to make software development projects successful. Because of this reason, cross-certification is becoming very common phenomenon where a tester is learning technical languages and a developer is learning quality assurance techniques, for example. 

ISTQB Foundation Level is one of the most popular certifications in software quality assurance and thousands of people appear for this test every year. We, at Testing Algorithms, wanted to help the aspiring candidates of ISTQB Foundation Level by providing a simple excel tool to practice with 500+ sample questions.

​In order to access this tool, please register using the following link:

https://www.testingalgorithms.com/registration.html

With this registration, you can also access the unique automated test case design solution invented by Testing Algorithms and the eBook "We Are All Pokers: A Different Perspective on Software Testing".

Note that, all tools, products and books of Testing Algorithms are free and will be free forever. However, you can give us "return gift" with whatever amount you thing they are worth. 

If you have any questions, please contact us as support@testingalgorithms.com.

All the best for your ISTQB Foundation Level!

I was buying a car for my wife a few years back. We did a lot of homework and decided on the brand, model and color of the car that we wanted. While entering the showroom, we were pretty sure about what exactly we were looking for and we thought it would be a very quick transaction.

Then the dealer started giving us hundreds of options beyond the brand, model and color of the car. Tilted glasses or not, moonroof or not, alloy wheels or not, and the list went on and on. The one that caught our attention was, whether leather seats or not. Although the earlier questions seemed more or less straight forward, this question was a tough one for both of us.

After a long analysis, we finally decided to go for it!!!

And then came this additional information from the dealer. For the mid west weather, we would definitely need heated seats if we want leather ones.

Eventually, we didn't buy the one with leather seats because, considering the additional value we were getting, this double investment was not worth to us.

Sometimes, in software testing world, we do not realize that we make similar uninformed choices. We first buy licenses of expensive test design, test automation or test management tools and then we pay a lot of money either to hire skilled people or to train existing associates so that the tool can be used in the organization; without even analyzing whether this double investment is worth the additional value or not.

Testing Algorithms, LLC. offers a simple automated test case design solution that doesn't need any specialized and technical skills that a Model Based Testing tool needs. Even a non-technical person can use this methodology to create better test cases 10x faster.

Visit www.testingalgorithms.com for more details.

Believe it or not, zero!!! It's only the representation of test cases that changed! 

Testing is all about simulating a user's experience. And test design is all about planning to simulate as many variations of user experiences as possible in a limited time and effort.

In last two decades, the simulation of user experiences evolved to more mature processes over time. It started with record and playback and passed through reusable functions, data-driven frameworks, keyword-driven frameworks etc. The latest entry in this list is codeless automation.

But what had changed in test design? Nothing!!! It is still the same process of testers thinking about various test conditions and documenting, as it was 20 years ago. With the advent of Agile, however, the format of test cases got changed. In present days, we mostly use the given-when-then format test cases that can be easily integrated with the test automation tools.

In early years, the purpose of test case development was to make sure that a stranger, with no knowledge of software testing, should be able to execute the test cases and find defects. Later Agile brought a tester's role much closer to the role of a Business Analyst or a developer. But did that make the test design process capable of finding more defects?

The question is, instead of focusing more on 'how', shouldn't we address the 'what' part of the problem first? Visit www.testingalgorithms.com for similar posts.

As per the ISTQB study material, the definition of software testing is "a process of executing a program or application with the intent of finding the software bugs."

But to me, software testing is a different poker game where a tester 'pokes' an application under test using various input actions and data combinations and compares the observed behavior of the application with its expected behavior. The primary dilemma in determining a test strategy is 'how to intelligently poke the application considering limited resources and time?’ To me, this sounds more like an optimization problem.

I have seen many testing teams come up with test cases for an application without giving much attention to the optimization aspect of the problem. Traditionally, the complete set of functionalities of the application under test is broken down into transactions, then into test scenarios and then into test cases with steps and expected results. However, this manual exercise often leads to a big number of repetitions and missed requirements in the test suite created. This is because a structured thought process and an effective optimization technique is usually missing in the process.

If we look at software testing as a special case of the poking game mentioned above, a mathematical optimization problem can be formulated that will generate minimum number of test cases that eliminates all gaps in test coverage.
​
We, at www.testingalgorithms.com, have come up with a process that makes software design process much faster, better and cheaper.