This is an Agile question. Why cars have brakes?
 
The purpose of a car is to move people and things from one place to another. And the performance of a car is generally measured by parameters like how fast it can go and how quickly it can pick up speed.
 
But, if that is only the case then why just having a gas pedal is not enough? Brakes waste both time and gas anyway! Why cars have brakes then?
 
I think we all know the answer. It's for safety.
 
And I am actually talking about documentation in Agile.
 
Document is a waste unless it is necessary for safety.
 
But when documentation becomes necessary for safety?
 
Well, I have seen situations where everyone perceived a user story (and its acceptance criteria) completely differently. It ended up in a car accident because it didn't have a brake!
 
May be this is one of the reasons why most scrum teams are very stressed in today's world.
 
Agile Manifesto says "Working software over comprehensive documentation". And most of us tend to ignore the word comprehensive, consciously or unconsciously.
 
What would make this easier for everyone is, if we had a process to create enough documentation (just to bring everyone on the same page) that doesn't waste any time and effort.
 
For example, if we had a process where, on clicking a button, optimum set of test cases in the organization-specific format, requirement traceability matrix and standardized use cases and process models are instantly (i.e., automatically) created from the user stories (written in a specific way), it would have made things much easier.
 
And this is exactly what we, at Testing Algorithms, are trying to accomplish based on our years of research. Please note, our purpose is to help the software development community and our solution is a gift to all. However, you can choose any amount (including zero) for giving us return gift, if our solution helps your organization.
 
Please register if you are interested to try something new.

I have studied Statistics as a student and then spent most of my professional life doing software testing! It's always been my curiosity to find out how analytics can help in identifying various patterns while testing a software under development. One of the specific areas that always attracted me was the test management where I thought inferences about the performances of the development and testing teams could be drawn based on statistical data analysis. And, as part of that investigation, I found out that the information contained in the logged defects tell us many stories.

In one of my previous projects, we were using a standard defect management tool where individual defects were following the following workflow:

While looking at the defect metrics, I always made the following assumptions about existing defects:

1. Defects staying in New status for a long time indicates that there might be a problem with the defect triage process. Either triage should be performed more frequently, or there are many requirement gaps that are causing the confusion about whether an anomaly is a defect or not.

2. Defects staying in Open or Reopen status for a long time indicates that there might be a problem with the performance of the development team. Clearly, they are not able to fix defects effectively and efficiently. Either the development team is understaffed, or they need more technical training.

3. Defects staying in Fixed status for a long time indicates that there might be a problem with the performance of the code deployment team. It is an indication that the testers can't retest the defect yet because the updated code is not available in the test environment.

4. Defects staying in Retest status for a long time indicates that there might be a problem with the performance of the testing team. Clearly, they are not able to retest defects effectively and efficiently. Either the testing team is understaffed, or they need more training on testing processes or the application under test.

So I found out a way to measure how long the defects are staying in these statuses so that inferences can be made about the root cause and appropriate actions can be taken to improve the speed and/or quality of testing.

I noticed that the defect management tool captures and maintains the history of status changes for all defects. And also, a report containing that history can be exported to excel format. So, using my little coding knowledge, I was able to write a small program that parsed through that excel report and captured the duration of stays of all defects in various statuses. The output of my program looked something like this:

New: 1, 5, 3, 7, 5, 2, 3, 1, 7. (Note: There was total 9 defects)

Open/Reopen: 5, 8, 4, 2, 6, 8, 7, 8, 9, 4, 2. (Note: 1 defect got reopened 2 times)

Fixed: 4, 5, 2, 7, 4, 6, 8, 3, 2, 9, 8. (Note: 9 defects were fixed 11 times)

Retest: 3, 6, 7, 2, 6, 8, 4, 6, 3, 9, 8. (Note: 9 defects were retested 11 times)

I assumed a Gaussian or Normal distribution for all the duration data. A Normal distribution looks like this:

So, while doing testing, I constructed normal distribution for each of the 4 sets of data (i.e., for New, Open/Reopen, Fixed & Retest) on a daily basis to understand how this duration is increasing or decreasing over time. And to to do this, I used box plot diagrams. Following is a example where box plots are constructed on a daily basis:

Note that, the individual boxes are separate normal distributions and viewed from the top. Anyway, I kept plotting the distributions in this way for all of the 4 sets of data (i.e., for New, Open/Reopen, Fixed & Retest) separately. This helped me identifying the pattern and to guess the root cause of the problem so that I could take necessary actions to bring the speed and quality of testing on track, as and when needed.

I have tried this technique many times after that in both Waterfall & Agile projects and it helped me every time!

Over the last few years, many organizations have realized that software development is not a production process; rather it is more of a Research and Development process, as Agile Manifesto indicated in 2001. Since then, many approaches and techniques were crafted that have been successfully used and still being used in these organizations. 

Business Driven Development (BDD) is one of them, and probably the most popular today. It uses a Given-When-Then (i.e., Gherkin) statement that serves multiple purposes:

1. Elaborates the product feature with details and examples,
2. Aligns the Definition of Done (DOD) with business users,
3. Specifies the acceptance criteria of a user story, and
4. Accelerates Test Driven Development (TDD) using test automation.

However, the current practice in the industry is to write the Given-When-Then statements manually, as a team.

But what if we go up one more level of abstraction? In other words, can we capture the feature, or the behavior, of the software under development using a much simpler model and generate not only the Given-When-Then statements, but also the optimized manual test cases in Quality Center format, various types of requirement traceability matrices, test  case priority matrix, traditional use cases and process flow diagrams?

We, at Testing Algorithms, came up with a solution for that based on our years of research. It is a methodology that helps in structured thinking and representation of the application behavior so that the optimization and visualization can be taken up by a mathematical algorithm. Based on our case studies, this model is able to create all artifacts, including better quality test cases, ten times faster.

Agile is about innovation. And we believe in helping each other to grow as a community. So we have decided to let everyone use our research-based approach for free. Our website is https://www.testingalgorithms.com. 

If you want to try our requirement analysis and test case design  solution, please register using https://www.testingalgorithms.com/registration.html.

For any questions, contact us at https://www.testingalgorithms.com/contact-us.html.

​"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!

“Share your knowledge. It is a way to achieve immortality.” - Dalai Lama

Few years back, I and my friend Palash started a research to find out whether, during a software development, there is an easy way to capture business requirements that would automatically translate those requirements to an optimum set of test cases covering maximum test combinations. Last year we were able to find a solution and that's when we started Testing Algorithms, LLC.

In today's world, more than half of the defects originate from ambiguous and unclear business requirements. Moreover, in most cases the projects end up spending a lot of time and effort in over-testing the application under development. Our unique and patent-pending automated test case design solution claims that it creates an optimum set of test cases 10-times faster and covers 100% (under certain assumptions) of the requirement combinations. Refer to our case studies.

The purpose of our organization is not to selfishly accumulate money by selling the licences of the product that we have created. We believe in helping each other, especially to the business analysts and software tester community whom we professionally grew with, is the right way of living. We think that our unique skill, which we have developed during our years of research, should be shared with each and every tester of the planet with a hope that it will make their lives a little better.

With that objective, we made our product and techniques available to everyone in August 2016. Anyone, who is interested in trying this new process, can register in our website to get a copy of our product. We also put in place a way to give us return gift if our users find it useful. Refer to our videos.

But we recently received some feedback from our users where they said that a little more guidance on using the solution would be even more helpful. As we are both teachers, we decided to start a training program for all who are interested in using our techniques individually or in their organizations, against a nominal fee as compensation for our time. As always, the product is and will be free. And you will be able to keep your knowledge and use them to stand out for the rest of your professional life.

As part of this course, we are planning to have 2 sessions of 2 hours each on Saturday & Sunday morning EST/CST. Also, it will be an online training via Skype with screen-sharing and lots of hands on assignments for practice. The course fee per person will be approximately $200. Certificates will be issued to all participants at the end of the course to recognize them and to help them getting the training fee reimbursed by their employers, if needed. We are planning to have our first training sessions in the beginning of January 2017.

I would love to hear your thoughts and whether you will be interested in attending the course. Feel free to let me know if you have any questions and/or suggestions.

P.S. No matter whether you take this course or not, I am always available (abhimanyu@testingalgorithms.com) if you need any assistance in using our solution.

We, testers, test software applications to find bugs. We are called bug-hunters. But if we take a step back and look at the mirror, we will see ourselves as someone much more important than mere bug-hunters. We are the trust-builders. Just like the bomb disposal squad. 

When a bomb is disarmed, civilians are no more scared to use the street where the bomb was originally found. That's because people trust the bomb disposal squad and the techniques they use to disarm it. Well, in a similar way, the business users trust the testers and their testing processes at the time of using the software application in their day-to-day business. 

But the question is, how do we disarm a bomb? How do we ensure that it is not dangerous anymore? Is it a science or an art? Can we increase the reliability and efficiency of a techniques we use? Can we disarm it faster? Can a robot do it? 

This book is the outcome of the philosophical investigation to find answers of all these software testing questions. To read this book, a little knowledge of a software development process is helpful but not necessary.

The book is available in amazon.com:
https://www.amazon.com/dp/B01LXRTVDW/ref=rdr_kindle_ext_tmb

The book is available in testingalgorithms.com for our users:
https://www.testingalgorithms.com/ebook.html

Note:
All users of the automated test case design solution of Testing Algorithms get the eBook for free. They can choose to give return gifts based on the perceived value of the book.

Link to register as an user of Testing Algorithms:
https://www.testingalgorithms.com/registration.html 

A software application is very similar to a building.

In a building, a person can visit various rooms and use connectors and doors to go to other rooms. Rooms are of different colors and sizes and have their own purposes and personalities. Some doors are even locked and only those having the right authority have the keys. 

At the time of building one, a story-by-story approach is usually taken by the builders. They first build one story and then they build the next one on top of it.

(Do you see the similarity? In Agile software development we call them user stories!!!)

In the example of the above picture, the builders developed each story perfectly on top of each other. They put every effort to make sure that each individual story is as per the customer's expectation.

But, in this whole process, what they failed to do was, to check the foundation of the entire building after each story was built! No one even noticed that there was an increasing problem with the center of gravity of the building!!!

The case of Agile software development is very similar. Sometimes techniques like paired programming and TDD make the testers lose focus on the bigger picture.

This is why Testing Algorithms recommends the evolution of a regression test suite parallel to the software under development. The regression suite should be enhanced, prioritized, executed and maintained as part of each sprint.

In one of our recent case studies, we applied our methodology for an online book store that was being developed using Agile methodology. Below is one of the user stories that was in the scope of the first sprint:

User Story:
As a customer, I want to add books to my shopping cart, so that I can build a list of books I want to buy

Acceptance Criteria:
a. I can add books to my cart from search results
b. I can edit the quantity of a specified book
c. I can remove a book from my shopping cart
d. I can proceed to check out from my shopping cart

Using Testing Algorithms' solutions, following test cases were created for add book, edit quantity and remove book functionalities.

Test Cases - Add Book:

Test Cases - Edit Quantity of Book:

Test Cases - Remove Book:

Now the question is, are the given-when-then statements (i.e., test cases) better 'definitions of done'? Should the original acceptance criteria be replaced by them?

There are various ambiguities in the traditional acceptance criteria that were identified while creating the model using Testing Algorithms' approach, as follows:

1. Can a negative quantity be selected while adding a book into shopping cart?
2. How many ways a customer can land on the Search Page?
3. Are cancel buttons present when a book is being added, edited or removed to shopping cart?

Clearly, the traditional acceptance criteria were incomplete. Also, as a matter of fact, creation of the test cases (i.e., Gherkin statements) didn't take any additional time to create. In the product backlog grooming session, before the sprint started, Testing Algorithms' solution was instantly used to create not only these test cases, but various other documents including use case diagrams, process flow diagrams and manual test cases with expected results.

Visit https://www.testingalgorithms.com/online-book-store-agile.html or contact support@testingalgorithms.com for additional details of Testing Algorithms' solution.