#CAST2015 Founder’s Brewing Tuesday night event – 8pm to 11pm

We have reserved the Centennial Room at Founder’s Brewing tonight – Tuesday, Aug 4 from 8-11 after the reception ends.

It is a cash bar but will have some free appetizers available and a private space for all of us to enjoy some good beer and good conversation. If you have your favorite tester game bring it with you!


Address: 235 Grandville Avenue Southwest, Grand Rapids, MI 49503

Any questions/concerns please feel free to ping me at abantz@salesforce.com.



My Stump Speech


My name is Alex Bantz and I am writing about why I am interested in a spot on the AST Board of Directors and hopefully some reasons why you should will want to cast your vote for me.

Some (or many) of you may not know me so here is a brief intro on myself as well as my experience in the field of software testing. I currently reside in Indianapolis, IN and work at Salesforce as a Director, Quality Engineering for the Marketing Cloud. I am a proud father of 3 wonderful boys. In my spare time, I enjoy playing tennis and am an avid reader. As my bio states, I have been in the software testing field for 15+ years now.

My participation in AST to this point has been primarily on the educational side – have the Bug Advocacy course still left to go and this will be my 5th CAST. I will be facilitating a few sessions at this year’s CAST and looking forward to being more involved.

Why am I pursuing a spot on the board?

I have always been geared towards community service and this has become my testing community and really want to be an active participant in serving the AST membership and promoting the context driven test community. AST and the community has given so much to me, I would like the opportunity to give back.

Why me?

I am open minded and easy to do business with. I can work with different personalities and am open to new and different ideas.

I am passionate about professional software testing as well as AST. I want to share and spread that passion to others that are either just finding their footing and way to being context driven as well those that maybe have gotten in a rut and need help getting out of it.

I can lead and work on initiatives solo, but also believe in teamwork. We can do so much more as a team than we can do solo. I will do whatever it takes to get the job done and treat people with respect and candor.

Areas of Focus?

Test Leadership/Management – I would like to bring a focus to leadership and management of testing to better educate and develop leaders to cultivate, motivate and champion context driven testers in their organizations.

Communications – I am interested in working on marketing and communication programs for effective outreach and inclusion of the membership.

Generate More Visibility – Want to reach outside of the bubble or “preaching to the choir” and generate more brand recognition of AST to others in testing as well as their dev counterparts. Surprised to find so many that have not heard of AST or CDT.

We talk a lot about what we want or plan to do as board members ,but what would you as members think or feel my focus should be if I were elected to the board? What areas do you feel need more and/or less attention from the AST board of directors? I believe a big part of this role is serving the membership so want to know what you think.

Thank you for your consideration,

Alex Bantz

Recommendations & Tips for #CAST2015 Attendees

I originally posted this leading up to CAST 2014 last year and some tips I put together from my previous times attending CAST. With #CAST2015 approaching wanted to share as believe they still apply to first time attendees as well those returning for more.


Some new items to add to the list:

Lightning Talks – Attend and/or participate. You have an interest in speaking and/or have an idea you want to share , but lack the confidence and/or have a fear of public speaking these are the perfect outlet/platform to dip your toes in the water and do it. If not, at the very least you should attend and listen and engage in the Open Season portions. My co worker and I did this last year and am glad we did.

Evening/Social Events – Even if you aren’t a drinker, these events and the time you have to engage, interact and get to know your fellow testers is invaluable. These events are almost if not just as beneficial as the conference itself.

Bring a Friend/Coworker – Don’t be selfish and keep all of this wonderful learning and conferring to yourself. Encourage your friends and/or coworkers to attend with you.  I started my CAST experiences flying solo my first 2 times. The next year we got that number up to 5 and last year 9. This year we have 15 of us that will be in attendance.

I find this helps the lessons and ideas sink in and gain traction more as now you have more folks on the same page and seeing the value of the ideas, techniques, etc. learning at CAST.

Another benefit is that you can have folks attend more sessions by spreading out and sharing the wealth. You are not limited to just those you as an individual are able to attend.

These are just tips that I thought of, would love to hear others you may have as well.

Lessons Learned Leading Context Driven Testers 2.0

Note: The original version of this article was posted here on July 7, 2015 – http://www.associationforsoftwaretesting.org/2015/07/07/leading-context-driven-testers/

Jeff and I received some well thought out edits/suggestion from Timothy Western and have applied them here. We think they better capture the intent and meaning of the ideas we were trying to convey.


by Alex Bantz and Jeffrey Woodard

Having experienced context driven testers as part of your team can be a lot like having a highly intelligent child. We expect that both you and your testers are adults, but the relationship dynamics are similar. Even though you are their leader/manager, you must be willing to accept that they will constantly be searching for ways to be engaged and challenged.

You must also be willing to give them some amount of freedom to reach their potential within your team. If you let your experienced context driven testers stay unengaged or unchallenged, you should expect them to get bored, distracted, or disengaged.

It is an interesting dichotomy where they can be most challenging to lead while also being the easiest people to manage. Here are some of the ways in which the dichotomy plays out.


If your coaching is a one-size-fits-all approach, you can expect that to fail miserably with an experienced context driven tester. They aren’t looking for you to you coach them on how to test. They are looking to understand how the team/project/organization got to be where it is now and how they can best contribute to moving it forward.

Your initial coaching conversations are more likely to focus on navigating the organization’s structure/hierarchy, along with the history of how it came to be. While you have your own ideas on how the tester will work within your team, you should expect that they will propose their own ideas. You are also likely to find yourself challenged on how the organization can be changed for the better.

Since you aren’t the experienced tester’s first manager, don’t be surprised if you receive some coaching yourself. Especially if the tester has previously held a leadership role. If you propose something, you can expect to be told it’s a bad idea if the tester truly thinks it is. Value their honesty and understand why they consider it a bad idea. Take the opportunity to get their help and build your idea into something better. Don’t consider it to be a challenge to your leadership. Be grateful for their feedback and use it to improve yourself and your team. In doing so, these challenges will help strengthen the bond/relationship as you come to a better understanding together.


One of the first things you will probably notice is they will question everything. They aren’t doing it to be difficult or challenge you. They question so they can understand the actual problem trying to be solved. Their questions are clarifying and often times provide you with another perspective to make a more conscientious decision.

You can’t just say “Go do this….” and be on your way. You should expect to be questioned and they lead by example in doing so. It shows a level of ownership, buy-in, and responsibility.  You cannot be a passive leader/manager.

The answers they provide may also not be to the question you asked or the answer you were expecting.  This can help you begin to think about how you are framing your questions and the information you really want/need which in turn leads to asking better questions.

Especially on established teams, they can highlight some inconsistencies and/or areas of improvement that you may be blind to as “we have always done it this way”. Once the questions start to come, it really highlights the holes in our processes and demonstrates that the direction is not as cut and dry as you once thought it was.

Adaptability & Flexibility:

Context Driven Testers are often times more adaptable and flexible than others.  They can jump into almost any situation and get to work quickly. They have a large toolbox of testing techniques and the awareness of what to use and/or not use in different situations.

It provides you flexibility as a leader where they can jump across different projects and/or technology stacks that aren’t easily siloed into one area. As needs and timelines change, it will make your life easier having these well rounded, professional testers on your team.

They tend to be very driven and motivated to give back by helping others stretch themselves through experimenting with new ideas and techniques and mature into better testers. They are generally willing to assist and share their experiences and techniques with their teammates when asked.

Setting Them Up For Success:

Leading also involves educating others in the organization as to what context driven testing is and how it is different from the traditional testing practices most are still accustomed. Highlighting and demonstrating the value the context driven tester brings to the team and organization shows that they are more than just test case creators and executors. Educating the rest of the organization to not only differentiate between the two styles, but also appreciate the tremendous benefit they provide is critical to success.

Finally, provide an environment where they are free to experiment and try techniques they feel best fits the situation. You can expect that they will not take a cookie cutter approach to testing and their methods may differ greatly from project to project. It is important to also set expectations amongst your development counterparts that this is occurring and why it is so advantageous.

About the Authors

Alex Bantz is a Director of Quality Engineering at Salesforce in Indianapolis, Indiana. He is a proud father of 3 wonderful boys. Alex has been involved in the field of software testing 15 years as both an individual contributor and in managerial/leadership roles.  He enjoys not only learning new techniques but also assisting others in their growth and development and is a vocal supporter of the importance of software testing.

Jeffrey Woodard is a Senior Manager in Quality Engineering at Salesforce in Indianapolis, Indiana. He has held test leadership/management roles at multiple times in his career.  Jeffrey believes leading context driven testers is definitely not for the faint of heart. It is never boring and at times very challenging. Leading context driven testers has proven to be incredibly rewarding in his own growth as a manager. Also, it has provided personal satisfaction that comes from working with talented, motivated testers that are always trying to improve themselves and those around them. He is presenting at CAST 2015

“Best Practices” for First Time #CAST2014 Attendees

Now don’t lie….when you saw the blog post title, how fast did your blood pressure spike? Did you open the blog post before firing back on Twitter? Did the use of “best practices” have no impact on you whatsoever?

Thought would start with a little fun, but as have been eagerly anticipating CAST 2014 in NYC, it made me think back on my first CAST and what an eye opening experience it was.

I always tell people there is nothing like your first CAST conference and had some tips/suggestions for those attending their first this week (not an exhaustive list) from my experiences.

  • Live it up – Be fully engaged and participate in your tutorials, sessions, open season, etc. Participate in the Tester Games, Tester Competition and everything the conference has to offer. Jump into a lunch table vs finding one in the corner by yourself.
  • Engage in Open Season – Engage and pay attention to the Open Season sessions. They are often times just as beneficial (if not more) than the actual presentations themselves.
  • Socialize – Attend the evening events and reach out to others during the breaks. You will meet some amazing people and they are willing to share their expertise.
  • Don’t Be Intimidated – A lot of the big hitters will be at CAST. You have read their books and articles, attending their trainings and followed them on Twitter. Don’t shy away when you have the opportunity to meet and introduce yourself. What I have found is they are eager to meet and help others continue their path and growth in the software testing field. Sure they may quiz you and challenge you, but you will be the better for it I promise.
  • Get Twitter Handles – If you aren’t following these folks already, you will want to. Not only is it a great way to stay in contact, but the articles folks share along with topics and problems at hand you can learn from and sometimes even offer help back as well
  • Don’t Be Afraid to Disagree – You don’t have to be a jerk about it, but if you feel yourself disagreeing or having a contrary opinion with someone don’t hesitate to share and offer it up as part of the dialogue. You may want to have some info/data to back up your claim, but this is part of conferring that we all talk about.
  • Confer, Confer, Confer – This pretty much sums up all of the above, but the more you put into the conference the more you will get out of it.

Now I didn’t do a lot of these my 1st CAST, but each year have done more and more. You will find by doing this that when you come back next year for your 2nd, you will know more people and people will know and remember you. CAST is not only a great conference, but now it also feels like a reunion of sorts and looking forward to seeing my friends & colleagues again and meeting new ones as well.

Looking forward to seeing/meeting you in NYC!


Testing With Cats?

Our new family member, Sally:


We recently decided it was time to start looking at adding a canine member to our family.  For some background, we have 3 young boys (8 Years old, 2 years old and 9 months) and an adult cat (approximately 13 years old).

Our oldest had a bad experience very young with a playful puppy so is a little hesitant when it comes to dogs. Our 2 year old is obsessed with dogs and goes on walks looking for them all the time. HE also has about 10 stuffed dogs in his possession.

Some of the criteria we used when searching for the dog is as follow:

  • Good with kids: We need a dog that is relatively patient and easy going as with the 3 young kids am sure they will test its patience on a regular basis.
  • Good with cats:  We wanted to make sure the dog we adopted would be good/ok with cats. We didn’t want our cat to be limited to where he could/couldn’t go in house in fear of our new dog.
  • No puppies: Wanted a slightly older dog that while still energetic, a little more mature and calm when needed.
  • Medium sized dog: we didn’t want too large of a dog for space and concerns with knocking kids over, etc.
  • Non-jumper:  This came from our 8 year old. He didn’t want a dog that jumps up a lot as scares him from his prior experience as a smaller child.

We located a dog we were interested in located down in Linton, IN, around a 2 hour drive. She was described as calm and laid back.

Now to the Topic at Hand…

We are now getting to the subject of this blog post. One of the key things before deciding to make the trip down was for them to test her and how she responds to cats. A couple days later, I received a response that they had tested her with cats and that she  tested well and was actually intimidated by the cat they put her in with. So in effect was determined “test passed”. Although she did use some safety language – “I think she will do just fine with cats.”

When we got home and settled in, Dog sees Cat. Cat Sees Dog. Cat takes off. Dog gives chase. Not in an “I’m going to hurt you” way but a “let’s play” way. But, not exactly what we were expecting when heard “tested well with cats”.

As I am in the middle of BBST Test Design training, the functions and variables jumped out to me and motivated me to put together a blog post.

  • Function: Good with Cats
    • A couple Variables stick out: (I am sure folk can find many more in this example).
      • Cat: Is the cat afraid of the dog? Yes or No gives much different results
        • Test Cat: They tested her with a cat that had no fear of dogs and went right up to her. In this case, she cowered and was intimidated.
        • Our Cat: Our cat is skittish of dogs and showed fear by running away. This triggered our dog to give chase rather cower in intimidation.
        • Historical Example: My mom had a dog and 2 cats at 1 time. The 1 cat could care less that the dog was there and would go aboThe other was always scared of the dog. So when we would let them out, he would dart for the fence.  The dog would chase after the scared cat EVERYTIME and never once gave the other much of a bother.
    • Setting:  In shelter vs. at home. At home pre-adjustment vs. At home  and increased comfort level of dog
      • Shelter: She had been there 3 weeks and in a loud environment and adjusting to contact.
      • Our House:  At this point, think the cat variable biggest impact, but will be interesting to see how this impacts her behavior here vs. other areas as she moves from adjusting to our house to feeling like this is her house too.
    • Take Away:
      • This shows the importance of using many techniques to test the different variables in a function/situation.  Superficial coverage to determine “passing” could only give you half the story and/or miss something critical.
      • We may jump to a conclusion on finding a certain pattern and stop short of finding the real issue/answer.
      • Changing any variable can impact the results of test/behavior and then combining multiple variables exposes other potential differences and/or more confidence in consistent behavior.
      • We need to research and figure out the best way to introduce Sally, the Dog, to Will, the Cat, in a way where they can live and interact in peace.  I personally think it would take the cat standing his ground 1 time to set the dog straight.
      • Just because they test out find with one cat does not translate to being great with other cats.
      • Overall she has acclimated to our family very quickly and loves our boys already. Our 8 year old who generally shies away from dogs is on top of the moon and super excited. It is fun to see. She loves to snuggle and walks well on the leash and sleeps in crate without issue.
      • Another area to train her is how she responds/ interacts with our 2 year old. She has made a few warning noises/ moves to our 2 year old if he startles her or is playing around her tail.

Progressive vs. Non-Progressive Bugs

In the past year or so, I have used this comparison when talking with our product and development teams. I highlight the differences in what I term Progressive and Non-Progressive Bugs.  While they are both in the bug category, one is more helpful in gaining insight into the state of the system as well as moving us along the path to even more insight.

Others may have varying terms/definitions for the same thing, but I have found this to be helpful in getting my point across when discussing perhaps a lack of Unit and Integration testing before a build, a late arriving change in the release process, etc.

Non-Progressive Bug:

I refer to a Non-Progressive Bug as those that most likely should have been caught in Unit testing and block additional testing. Yes they are a bug, but they aren’t a bug in the type that provides additional information to the tester on the actual functionality being delivered.

An example would be:

  • Development is working on a Create User module.
  • They build & deploy the code for you to test.
  • When you receive the build and open the Create User module, the Create button is not functional – either disabled or generates an error.

This grinds additional testing to a halt and this bug does not need any special type of skill in testing to come across.  It is a bug that must be logged and fixed to move forward, but doesn’t move the process forward to getting this module ready for release and provide the stakeholder with additional information as to its readiness.

Progressive Bug:

A progressive bug is one where you are able to dig your teeth into the code and really explore the boundaries and the bug detected provides you important information to the readiness, stability, etc. of the code under test. It also provides you perhaps a new pathway to go in your round of testing that you may have overlooked otherwise. It continues to allow you to provide stakeholders relevant data to make the informed decision on state of the feature, the risk associated and additional steps needed to get it to a state where you all feel comfortable releasing it to the public.

An example would be:

  • Development is working on a Create User module.
  • They build & deploy the code for you to test.
  • You begin testing the new Create User module and in testing decide to test it for XSS (Cross Site Scripting) vulnerabilities.
  • Your test uncovers that the module does in fact have vulnerabilities in the code.

This is critical information to have and especially in this day and age of so many security exploits occurring across the globe. This is data you can take to the stakeholders and they then have critical information to make the decision on what to do next. This could spark you to try additional security vulnerabilities and/or allow you to move on to other areas of the module to do more testing to gain more insight/information into the feature under test.


In conclusion, both of these types of bugs need to be resolved. The difference is Non-Progressive bugs need to be fixed in order for the tester to do the actual testing and begin finding Progressive Bugs that will allow them to provide relevant and accurate information to the stakeholders which in turn allows them to make better formed decisions on direction, readiness for release, etc.