This interview with Bob Galen is part of our series of “Testing Smarter with…” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

Bob Galen is an Agile Methodologist, Practitioner & Coach based in Cary, North Carolina. In this role he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is Director, Agile Practices at Zenergy Technologies, a leading agile transformation company.

photo of Bob Galen
Bob Galen

Personal Background

Hexawise: You have a background in agile software development: what led you to expand the scope of your advice to include a particular focus on software testing?

Bob: My background is in software development or as a developer. Early in my career, I accelerated in leadership roles and began to lead testers (and other roles) as well as developers. I felt that it would be impossible for me to lead folks whose role and skills I didn’t understand, so I sent myself to school for testing.

Hexawise: Which person or people have had the greatest influence on your understanding and practice of software testing?

Bob: Ross Collard taught my first 5-day workshop on the art and practices of software testing. To this day, he’s had a great influence on me. As has, Rob Sabourin, Lisa Crispin, and Janet Gregory.

Hexawise: Who have been your greatest influences from a management perspective (not necessarily  specifically related to software testing)?

Bob: I’ve been fortunate enough to work with some outstanding leaders whom I consider mentors, colleagues, and friends. One is the late Rick Bozzuto who I worked with while at Micrognosis. The other is Ralph Kasuba, who I worked with at iContact, Teradata, and ChannelAdvisor. Each of them had a more modern servant-leadership style that I learned from. In particular, Ralph was a great role model in how he was egoless and truly walked his talk.

We have to view software testing in the same way we view software development. It’s a crucial skill, activity, focus that needs to be done by professionals in order for us to deliver world class products.

Hexawise: What one or two software testing-related experiences have you found to be most personally satisfying in your career?

Bob: They’re always from a leadership perspective and they align with my leadership style and agile approaches as well. I have unfortunately, quite often take on “beaten down” testing teams. In that they are overworked, undervalued, misunderstood, and second-class citizens to their development counterparts. Turning this around on at least 5+ occasions has been one of my greatest pleasures. Seeing testers “rise and shine” is something I cherish.

Views on Software Testing

Hexawise: What do you wish more developers, business analysts, and project managers understood about software testing?

Bob: I don’t think it’s about software testing as a discipline itself. Although I always encourage folks to become more well-rounded, as I did. I guess I more want them to be more respectful of the discipline of testing and empathetic and respectful of their tester/testing colleagues. We have to view software testing in the same way we view software development. It’s a crucial skill, activity, focus that needs to be done by professionals in order for us to deliver world class products.

Hexawise: What advice do you have for those responsible for managing software testers?

Bob: Well, I think I’ve answered part of this before. That is, hopefully understanding the depth and breadth of the science of software testing. So that you can respect it, it’s value and its practitioners.

A current trend, largely driven by agile adoption, is to have developers serve as SDET’s or software development engineers in test. And by doing so, these testers typically report to development management. I generally think this reporting relationship causes the testers to struggle to differentiate themselves. And this isn’t a tester problem. It’s a development leadership challenge to better understand and support the testers and testing.

Hexawise: Describe a view or opinion about software testing that you have changed your mind about in the last few years. What caused you to change your mind?

Bob: I’ve been fairly consistent in my views on software testing for quite a few years. And I really haven’t changed my mind. I’ve shifted though. For example, I’ve shifted towards valuing Exploratory Testing more and more as a valid testing tactic. Especially in agile contexts. I’ve also shifted my views towards test automation strategies. Moving away from single-source tools and UI-driven strategies. But I think of these as more evolutionary than 180-degree shifts.

Industry Observations / Industry Trends

Hexawise: What specific suggestions for testers working within an organization using agile software development methods?

Bob: Stop thinking of yourself as a tester that is independent of the developers. Meaning waterfall or silo-based thinking. Instead, realize that if your testing on an agile team, you are part of the team. And the overall team is responsible for the testing decisions and execution and for the overall product quality.

Hexawise: Have you seen agile retrospectives used in the testing context? What advice would you give those interested in including testing in the retrospective process?

Bob: Yes, well, not in the testing context. In the whole-team context where testers are part of the team and the team has periodic retrospectives. I would say that an agile organization has a whole-team responsibility to include all team members in any retrospectives. Period!

Hexawise: Have you seen a particularly effective process where the software testing team was integrated into the feedback from a deployed software application (getting feedback from users on problems, exploring issues the software noted as possible bugs...)? What was so effective about that instance?

Bob: Again, in agile, it’s whole-team. And as such, then the product owner should be facilitating this feedback for the entire team to experience. Customer engagement and transparent interactions are key for the team to effectively deliver software for their customers. Software that delights them and fully meets their needs.

Stop thinking of yourself as a tester that is independent of the developers. Meaning waterfall or silo-based thinking. Instead, realize that if your testing on an agile team, you are part of the team. And the overall team is responsible for the testing decisions and execution and for the overall product quality.

Hexawise: Large companies often discount the importance of software testing.  What advice do you have for software testers to help their organizations understand the importance of expecting more from the software testing efforts in the organization?

Bob: I know. And it continues to make me sad. As far as organizational understanding, I’m not sure they can. One of the advantages of agile teams is the testers don’t have to “sell” their importance or value. The entire team does. So agile instances can help with this.

But the other point is that some organizations are “stuck”. And the only thing they might understand is testers moving on to greener, more supportive, pastures. Voting with their feet, if you will. Perhaps a large drain of these great folks will get their attention?

Staying Current / Learning

Hexawise: I see that you’ll be presenting at the The Triangle Information Systems Quality Association conference in North Carolina this month. What could you share with us about what you’ll be talking about? What gave you the idea to talk about it?

Bob: I’ll be sharing on various aspects of testing (automation, team dynamics & tools, and leadership dynamics) at the conference. These are workshop topics that I’ve been co-delivering with my colleague Mary Thorn for a number of years. They are usually packed and the feedback is very positive, so I think the topics are still quite relevant and useful to our “clients”. Which is the why behind our sharing.

Hexawise: What advice do you have for people attending software conferences so that they can get more out of the experience?

Bob: Network. Even if you’re an introvert, force yourself to engage with others, have conversations, and extend your network for future learning. The essence of conference is “confer”, so folks need to be prepared to do that.

Hexawise: Do you have advice for testers looking to move into roles that involve supervising or other management responsibilities?

Bob: No. I’d actually recommend that everyone stay away from roles/titles that emphasize “supervision” or “management”. Instead, focus on stepping up to lead from wherever you are. Leadership skills are key and, again, you should find opportunities in agile teams to lead.

Here are two presentations I've made that might provide further insights into my thinking:

TechWell interview on management: Why Managers Should Stop Managing and Start Leading.

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf?

Bob:

Profile

Director, Agile Practices – Zenergy Technologies

Bob Galen is an Agile Methodologist, Practitioner & Coach based in Cary, NC. In this role he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is Director, Agile Practices at Zenergy Technologies, a leading agile transformation company. He is also President and Head Coach at RGCG.

Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing and team leadership. He is a Certified Enterprise Coach (CEC), Certified Scrum Product Owner (CSPO), and an active member of the Agile & Scrum Alliances.

He’s published three agile focused books: The Three Pillars of Agile Quality and Testing in 2015, Scrum Product Ownership, in 2009 – 2nd Edition in 2013, and Agile Reflections in 2012. He’s also a prolific writer & blogger and podcaster.

Bob may be reached directly at: bob@rgalen.com.

Links

Podcast: Meta-Cast, an agile podcast Bob's Blog Book: Three Pillars of Agile Quality & Testing Twitter:  @bobgalen LinkedIn: Bob Galen Presentations: StarEast

By: John Hunter on Feb 13, 2018

Categories: Agile, Interview, Software Testing, Testing Smarter with...

This interview with Sudeep Chatterjee is part of our series of “Testing Smarter with…” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

Sudeep Chatterjee is a senior technology leader with 19 years’ experience with top tier Investment banks, FinTech and Consulting firms managing testing globally for enterprise-wide change programmes.

Currently Sudeep is working as Programme Test Manager/Head of Testing at Bank Of America Merrill Lynch within FICC - Global FX Technology group.

photo of Sudeep Chatterjee
Sudeep Chatterjee

Personal Background

Hexawise: If you could write a letter and send it back in time to yourself when you were first getting into software testing, what advice would you include in it?

Sudeep: Coming from a technology background, I did not give enough emphasis on learning business when I started getting into software testing. The advice I would like to include in the letter back to myself is the importance of learning about business.

Hexawise: What drew you into a career in software testing?

Sudeep: I found software testing as a branch of software engineering where one needs to have the diverse interest of learning both technology and the business for which the software is built.

Software testers needs to learn the technical architecture and the underlying technology stack to work with the developers and find technical issues as well as work with business users to learn how the application will be used and find the functional issues.

Besides this in test management other skills are also required like project and programme management, stakeholder management and strong influencing skills. For software testers - learning never stops and never a dull day!

Views on Software Testing

Hexawise: What testing practice(s) do you most wish the software testing community would embrace?

Sudeep: As organisations embrace Agile and DevOps practices, it is important for software testing community to embrace the change and the opportunities and threats it brings along. There is a growing need for software testers who have been in the industry for many years, as well as individuals who are joining this profession, to have clarity on how they will bring value and make a difference to the business.

As developers get more savvy with the business knowledge by working closely with operational users as well as adopting test automation practices like Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD), the old effectiveness and efficiency measures of defect leakage prevention to production by Quality Assurance (QA) is not relevant anymore.

Hexawise: Do you have specific suggestions for testers working within an organization using agile software development methods?

Sudeep: Software testers working within an organization using agile software development methods need to embrace the change of Agile and DevOps and first and foremost ensure that their role and goals in the agile team are well defined.

There are some agile teams where the Business Analyst or Product Owner writes the feature/story file which is then automated by developers using shared classes between unit and acceptance tests. These tests are run using automated tests at each build and software testers may have to review these tests and add additional tests as well as slowly learn the coding language (C++/Java/Python etc) and help developers write/maintain the automated testing framework.

There are other agile teams where the expectation is on test members to work with users and build the feature/story files using software testing techniques and ensure both positive and negative scenarios are covered as well as write the code to automate these tests.

There are other agile teams where tester write and execute tests manually in a sprint/release and different teams (separate test automation group) automate the tests in the following sprint/release. In this case the testers are manual but maybe having deep functional knowledge.

Depending on whatever the maturity level of Agile is in the team, it is very important to discuss and agree with other team members and management team what is the role of testers in the agile team vis-à-vis developers, business analysts and business users.

Industry Observations/Industry Trends

Hexawise: Have you noticed a change in the way the business side of organizations approach software testing in the last 10 years? What are the most significant changes? Have they made your life as a manager of software testing operations easier or harder?

Sudeep: The business side of organisations have really warmed up to software testing discipline of software development lifecycle in last 10 years and appreciates the value of structured test cycles before the product is released to production.

There are operations teams now who hire and train resources on the product and then allocate them to the project team as either Product Owner and/or User Acceptance Tester who have performance objectives to work alongside developers and QA members to ensure the product quality is high and limit issues in production. These resources may lack some knowledge about the technical aspects of software delivery but make it up with their deep functional knowledge which complements the development team really well.

in test management other skills are also required like project and programme management, stakeholder management and strong influencing skills. For software testers - learning never stops and never a dull day!

Hexawise: How would you like to see the practice of software testing evolve over the next 5 to 10 years?

Sudeep: The practice of software testing will really evolve in next 5 to 10 years with main difference being that emphasis will be given in grass roots computer science education about software testing. Not many computer science graduates currently aspire to be software testers and the primary reason being that software testing as engineering discipline is not explained to aspiring youths well.

Another big change that will evolve will be that senior management technology positions will have candidates who have been in software testing discipline rather than only having candidates from the development side. These leaders with a software testing backround will act as role models for the next generation of software testers.

As we get more CTO’s, CIO’s, Programme directors from software testing wing of the organisation rather than only development or architecture, will give more confidence for the new graduates that the software industry respect software testing as a profession and show there is sustained career growth model.

Staying Current / Learning

Hexawise: What advice do you have for people pursuing a software testing career? As a manager that must hire software testing expertise, what experience and skills are most valuable (what steps can software testers take to do advance their careers)?

Sudeep: People pursuing a software testing career need to be very clear why they have joined this field as unlike developers or architects, software testing is in constant threat of showing the value as there are always developers who are better technically than the tester and BA’s/Users who have more functional knowledge about the product.

As a Manager, when I need to hire software testing expertise, I go back to see what problem I need to get solved which cannot be fulfilled with current team set. If I need more automation done, then I would like to hire software testers or software developers who can build test automation frameworks and then integrate with DevOps tools for continuous testing.

If I need testers for functional testing then I look for software testers or business analysts with strong functional domain knowledge for e.g. for investment banking I would look for candidates with Chartered Financial Analyst (CFA) or Financial Risk Management (FRM) certifications.

As organisations embrace Agile and DevOps practices, it is important for software testing community to embrace the change and the opportunities and threats it brings along. There is a growing need for software testers who have been in the industry for many years, as well as individuals who are joining this profession, to have clarity on how they will bring value and make a difference to the business.

Hexawise: What books or blogs would you recommend for someone interested in management positions within software testing?

Sudeep: Management and leadership within software testing is no different to any other discipline of software engineering so reading the management books and models by thought leaders like Michael Porter, Peter Drucker, Stephen Covey, C K Prahlad, W. Edwards Deming etc. is very important.

Some of the management books I have personally found very useful are

  • 7 Habits of highly effective people by Stephen Covey
  • How to win friends and influence people by Dale Carnegie
  • Art of War by Sun Tzu
  • The first 90 days - Critical Success Stories by Michael Watkins
  • The Effective Executive by Peter Drucker

Profile

Sudeep is a senior technology leader with 19 years’ experience with top tier Investment banks, FinTech and Consulting firms managing testing globally for enterprise-wide change programmes.

Currently Sudeep is working as Programme Test Manager/Head of Testing at Bank Of America Merrill Lynch within FICC - Global FX Technology group.

Prior to Bank Of America Merrill Lynch, was Head of Testing with Lombard Risk, Barclays, UBS, GE and Accenture, primarily focused on building high performing multi-disciplinary testing teams and delivering testing for complex technology-driven business transformation initiatives.

A quality evangelist Sudeep loves to solve organisational problems through improved thought leadership and quality assurance and testing strategies.

Sudeep is active member of software testing industry and has been part of industry events like:

  • Speaker at QA Financial Forum London (2018)
  • Judge - European Software Testing Awards (2016 and 2017)
  • Judge - DevOps Industry Awards
  • Keynote speaker on European Software Testing Summit - Best Use of Technology in Testing
  • Conference speaker on National Software Testing Conference : How Is Software Quality Measured
  • Contributor of European Software Testing Summit Report 2017 and 2016

Twitter - @QualiAssure

LinkedIn - Sudeep Chatterjee

Some previous Testing Smarter with... interviews: Testing Smarter with Alan Page - Testing Smarter with Angie Jones - Testing Smarter with Michael Bolton

By: John Hunter on Feb 6, 2018

Categories: Agile, Career, Testing Smarter with..., Software Testing, Interview

This interview with Janet Gregory is part of our series of “Testing Smarter with…” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

Janet Gregory is an agile testing coach and process consultant with DragonFire Inc. Her peers voted as the Most Influential Agile Testing Professional Person in 2015.

She is the co-author with Lisa Crispin of Agile Testing: A Practical Guide for Testers and Agile Teams, and More Agile Testing: Learning Journeys for the Whole Team. She is also a contributor to other software development books.

photo of
Janet Gregory

Personal Background

Hexawise: If you could write a letter and send it back in time to yourself when you were first getting into software testing, what advice would you include in it?

Janet: Dear Janet, Talk with the programmers instead of writing bug reports. You will save time.

Hexawise: What one or two software testing-related experiences have you found to be most personally satisfying in your career?

Janet: I think it might be with an organization whose QA Director had the foresight to get the testers trained and understanding their new roles before the programmers did. By the agile teams were created and set up, the testers were ready and started at the same time. They didn’t have the normal issues of mini-waterfalls that most teams I see experience when they first transition.

Views on Software Testing

Hexawise: What testing practice(s) do you most wish the software testing community would embrace?

Janet: Learning to work through examples with their teams before coding happens so that the whole team has a shared understanding of what they are building. It makes it so much easier to test a stories and features. Of course, along with that, they need to be able to explore the system to find out what they didn’t think about.

Hexawise: In What’s a Tester without a QA Team? you and Lisa Crispin discuss the value of software testers working together with the entire software development team in an agile environment. What suggestions do you have for softer testers moving to such an environment from one that had the software testers separated from software developers and product owners.

Janet: I had to go back and reread the article you mentioned and it is still valid. My suggestions would be very much like they were then, perhaps with a few wording changes and maybe some updated links such as the SoftwareTestingClub is now The Ministry of Testing or (MoT).

I have a whole keynote at Star Canada on “Key Skills and Attributes for everyone who tests software.” That the video will be available after the conference.

Industry Observations / Industry Trends

Hexawise: How have you seen the practice of agile software testing evolve over the last 5 years?

Janet: I think the biggest change I see (not including technology changes), is the inclusion of operations – DevOps. With Katrina Clokie’s new book “A Practical Guide to Testing in DevOps”, I expect to see testers getting more involved in the whole development pipeline.

Hexawise: Large companies often discount the importance of thoughtful software testing. What advice do you have for software testers to help their organizations understand the importance of expecting more from the software testing efforts in the organization?

Janet: That’s a really big topic, but a couple of ideas I do have are:

  • testers need to understand what is important to the business, and be able to articulate the power of testing in words that they understand. For example, using metrics like the last release we put out cost the company xx,xxx.xx dollars in rework because we built the wrong thing, or $xx,xxx and xxx time fixing defects we missed because we rushed the release.
  • also, teams and testers need to be able to have the quality conversation and understand what it means to them in relationship to the rest of the organization.

Talk with the programmers instead of writing bug reports. You will save time.

Staying Current / Learning

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf? What blogs would you recommend should be included in a software tester's RSS feed reader?

Janet: I already mentioned Katrina’s book. Another good one is Elisabeth Hendrickson’s Explore It!. As far as blogs go, there are so many that it is hard to pick a couple. I often look at Testing Curator to see a nice consolidation of articles and blog posts.

Hexawise: How do you stay current on improvements in software testing practices; or how would you suggest testers stay current?

Janet: The first half hour (or hour) of most mornings is spent looking at new blog posts / articles, sometimes bookmarking them to read later in the day. I may see a new book mentioned on twitter that I want to read and order that. I also love going to conferences to see what people are talking about. I could probably spend all my time learning if I didn’t have to do anything else.

Hexawise: A great deal of making agile testing successful is a factor of how the organization practices agile within the organization, by which I mean things that are not exclusively related to software testing (so things like providing customer value, working together instead of in isolated departments, flexibility). What favorite sources (books, articles, blogs, people) on practicing agile methods (even if they are not focused on software testing)?

Janet: Two that come to mind are: Matt Wynn’s writings on example mapping, and Ellen Gottesdiener and Mary Gorman’s book “Discover to Deliver” for thinking about requirements elicitation.

testers need to understand what is important to the business, and be able to articulate the power of testing in words that they understand.

Profile

Janet Gregory is an agile testing coach and process consultant with DragonFire Inc. She is the co-author with Lisa Crispin of Agile Testing: A Practical Guide for Testers and Agile Teams, and More Agile Testing: Learning Journeys for the Whole Team. She is also a contributor to other software development books. Janet specializes in showing agile teams how testers can add value in areas beyond testing the software after it is built.

She works with teams to transition to agile development, and teaches agile testing courses worldwide. She contributes articles to publications and enjoys sharing her experiences at conferences and user group meetings around the world. Her peers voted as the Most Influential Agile Testing Professional Person in 2015.

Blog: Janet Gregory

Blog with Lisa Crispin: Agile Tester.ca

Twitter: @janetgregoryca

Related: Testing Smarter with Mike Bland - Testing Smarter with Angie Jones - Testing Smarter with Matt Heusser

By: John Hunter on Oct 11, 2017

Categories: Agile, Interview, Testing Smarter with...

This interview with Matt Heusser is part of the Hexawise “Testing Smarter with…” software testing interview series. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

Matt Heusser
Matt Heusser

Matt Heusser is a software craftsman with a deep background in software delivery and testing.

In 2014, Matt received the Most Influential Agile-Test Professional Award at Agile Testing Days in Potsdam, Germany.

Personal Background

Hexawise: If you could write a letter and send it back in time to yourself when you were first getting into software testing, what advice would you include in it?

Matt: My advice would be to trust your instincts and experiences more than what you read in books or online. Often the advice I read in books and online seemed vapid (shallow), or simplistic, or I felt it "just wouldn't work here." Eventually I realized that a lot of it (this was the testing advice of the 1990's) wasn't working well most places.

Today we have better advice. The time from research to publish is short, and there is a lot less "loss" in the system. Still, what works for Google and Microsoft might not work for your 20 person company, and what works for that cool, 100% physically distributed, 40 person software company might not work for your 2,000 employee insurance company. Take it with a grain of salt, trust your instincts - but always keep exploring and experimenting.

Hexawise: Which person or people have had the greatest influence on your understanding and practice of software testing?

Matt: It's hard to come up with a list of influences, but Cem Kaner, James Bach, Ken Pier, Brian Marick, Johanna Rothman, Lee Copeland, Jerry Weinberg, Kent Beck, and Ron Jeffries all come to mind.

Hexawise: What one or two software testing-related experiences have you found to be most personally satisfying in your career?

Matt: I remember once we wanted to get a insurance data extract out on a friday, but it had to be right. Serious students of testing will tell me you can never know that it is right - but non-serious student customers don't know that. I had about a half a day. The change was to one field, and we had the results in a database table. The table-to-file and the file transfer we had confidence in; the change, not so much. So I wrote my own computer program to loop through every current member in the insurance plan, over four hundred thousand, calculate the expected result, and compare them.

We found a small bug in the requirements; an edge case that was ambiguous. The programmer and I had interpreted the requirements in different ways that were both arguably correct. The "differ" program I wrote found the case, the customer explained that either was acceptance - and we shipped!

Views on Software Testing

Hexawise: What do you wish more developers, business analysts, and project managers understood about software testing?

Matt: A decade ago, when I went to the Google Test Automation Conference, one of the speakers said that automation was better because it was "repeatable." I almost stood up and asked aloud "so what?"

Every build of the software different. If the software is different, if the risk picture has changed, if we have some idea of what tests we ran before and how valid they might be on this build - why would we ever test the exact same way?

Software isn't an assembly line. Every build is different. The way we test it can be different, but I certainly don't see a ton of value in spending extra money to make sure we test things the exact same every time.

Turns out you don't need to remove the friction from handoffs. Often, you're better served to make communication cheaper and getting good at collaboration.

Hexawise: Can you describe a view or opinion about software testing that you have changed your mind about in the last few years? What caused you to change your mind?

Matt: It's going back a bit, but in graduate school, I wrote a paper "On the optimization of physically distributed requirements, development, test, operations, and management development groups" The body of the paper was considerably shorter than the title - the body was "You're Screwed."

At the time, the literature suggested that communication costs were high, so we needed get everything right prior to "the handoff." We needed to get every document, every bit of code, everything complete, consistent, correct, unambiguous, before "the handoff."

I knew that trick never worked, and thought the fix was co-location.

Then I learned about agile/XP, which was still focused on co-location - still, part of XP was making communication, collaboration, and change cheaper. Then I worked at Socialtext, where my co-workers were all over the world - Ingy took a skiing vacation in France, skiing during the day and working core hours at night. And it was far more productive than any other job I had ever had.

Turns out you don't need to remove the friction from handoffs. Often, you're better served to make communication cheaper and getting good at collaboration.

Hexawise: You have written about the benefits of lean thinking in software testing. What advantages do organizations gain when they adopt a lean thinking view of software testing?

Matt: You know that thing that happens, where you can't do your job because you filed a ticket and it will take the DBA's a week to add a column to a table, so you can't do your job, for a week?

Or whatever else it is? Right now I've got a contractor billing on my team with no laptop. He'll have it nine days after he started ... if we're lucky.

Typically, when a company goes to lean thinking, that kind of stuff stops happening.

Industry Observations / Industry Trends

Hexawise: Do you have specific suggestions for testers working within an organization using agile or lean software development methods?

Matt: It's hard to come up with examples without context, but generally, I'd start by looking at the delays we have in our job and the amount of multitasking. Be sure to include failure demand - things that should be reasonably expected to work the first time, but took a round of fixes. Often you'll find what should take an hour is taking you a week.

Hexawise: What do you see as the most powerful trends in the software testing field over the last 5 to 10 years? What trends do you believe will be the most powerful over the next 5 to 10 years?

Matt: The past ten years? Test-Driven Development, Continuous Integration, REST APIs that can be tested at the integration level, Virtualization, Lightweight Virtualization.

The next five? The promise of continuous delivery might just be realized. I realize that sounds like a lot of technical stuff, and I'm a process and people guy. The challenges of the next few years will be all skill, people and process.

Hexawise: There is still a widespread belief in fairly mechanistic software testing (checking) by some of those using software testing. Lean thinking, exploratory testing, etc. encourage engaging the minds of software testers. Are you optimistic about the prospects for tapping more of the potential software testers have going forward?

Matt: Oh yes. That's what I hope the next five or ten years are all about.

You know that thing that happens, where you can't do your job because you filed a ticket and it will take the DBA's a week to add a column to a table, so you can't do your job, for a week? ... Typically, when a company goes to lean thinking, that kind of stuff stops happening.

Hexawise: Have you seen a particularly effective process where the software testing team was integrated into the feedback from a deployed software application (getting feedback from users on problems, exploring issues the software noted as possible bugs...)? What was so effective about that instance?

Matt: My preference is for cross-functional delivery teams, so I get a little down on the term "test team", but yes, I have seen delivery teams where customer feedback was part of the process. One team that Justin Rhorman and I worked with managed a fortune 500 retail website; they had a process that periodically popped-up requests for feedback. The testers worked through these in a rotation, summarizing them, reporting them to management and working with management.

I think that worked well because of the rotation - no single bottleneck. If multiple testers observed the same feedback independently week over week, it was harder to dismiss.

Staying Current / Learning

Hexawise: You have spoken at many conferences. What advice do you have for people attending software conferences so that they can get more out of the experience?

Matt: Try to come up with three things to do on Monday that justify the investment. These things should be entirely within your power to do. They should not require training, a team-level change in process, particular learning time, purchase of tools or hiring of consultants. Things you can just do - that you will not ask permission for. (Your boss probably doesn't know what you do anyway.)

Then do it and tell the team about it. If you want to write a trip report, it should be a one-pager, and describe what you are doing, not what you heard.

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf? What blogs would you recommend should be included in a software tester's RSS feed reader?

Matt: I don't read blogs like I used to, instead I follow twitter and click on interesting links. A few weeks ago I wrote an article on 28 testers to follow on twitter that might be a good place to start.

As for books, I'd say How To Reduce the Cost of Software Testing, Lee Copeland's A Practitioner's Guide to Software Test Design, Lessons Learned in Software Testing and Jez Humble's Continuous Delivery book (the writing is a bit tough but it's worth it). I'd also suggest some non-testing books, like Out Of The Crisis by Deming, Peter Drucker on Management, and Taleb's Black Swan book.

Hexawise: We share an interest in seeing lean thinking concepts be adopted by software testers. How would you suggest someone interested in learning more about lean thinking in software testing do so?

Matt: You could try a google search for "heusser lean" and see what it returns, seriously I've written a lot. Here are two older articles that I think cover the start of it Applying lean concepts to software testing and The secrets of successful Lean software testing.

Profile

Matt Heusser is a software craftsman with a deep background in software delivery and testing. After earning his undergraduate degree in Math with a concentration in computer science in 1997, Matt began his career as a programmer, writing code in C, perl, PL/SQL, and Visual C++. Along the way, Matt was the initial organizer of Grand Rapids Perl User's Group ("Perlmongers"), earned a master's degree in CIS from Grand Valley State University, taught IS part time at night at Calvin College, and served as the initial lead organizer of the Great Lakes Software Excellence Conference.

After leaving Priority Health, a Health Insurance Company, in 2008, Matt went on to become a member of the technical staff at Socialtext, the world's first wiki company, where he worked with Audrey Tang, Ingy DotNet, and Dan Bricklin, the creator of the Spreadsheet, to help build a web-based spreadsheet/wiki that predated google docs. The test framework Matt worked on at Socialtext, WikiQTests, is documented as a case study (chapter 16) of O'Reilly's book "Beautiful Testing."

Matt left Socialtext in 2011 to become a full-time consultant. Since that time he reviewed Robert C. Martin's books "Clean Code", "The Clean Coder" (for which he wrote the preface) and "Clean Architecture." In 2014, Matt received the Most Influential Agile-Test Professional Award at Agile Testing Days in Potsdam, Germany.

Links

Blog: Creative Chaos

Twitter: @mheusser

Previous Testing Smarter with... interviews: Testing Smarter with Rikard Edgren - Testing Smarter with James Bach - Testing Smarter with Michael Bolton

Subscribe to the RSS feed for our blog.

By: John Hunter on May 23, 2017

Categories: Testing Smarter with..., Software Testing, Lean, Agile

I read a great post by Aleksis Tulonen Brainstorming Test Ideas With Developers and wanted to share it with you.

The ideas in the post provide a very efficient way to:

  1. increase the robustness and thoroughness of testing,
  2. prioritize among different testing ideas (both from a relative importance standpoint and from a relative timing perspective)
  3. surface new testing ideas that would not otherwise be considered
  4. provide some useful risk mitigation protection against the reality that "all models are wrong; some models are useful" problem

I'd suggest also scheduling a debrief with the same testers and developers a few weeks or months after the code was deployed.

At that time take a look at photos of the pre-testing Post It notes and a list of defects that slipped past testing and ask

  1. "what extra tests would we need to have added to have found these defects?"
  2. "what specific inputs did we forget to include?",
  3. would techniques such as pairwise testing have been beneficial?
  4. what areas did we spent a lot of effort on that did not result in learning much?
  5. what lessons learned should we incorporate for next time?

The idea of delibrately examining your software development and testing practices will be familar to those using agile retrospectives. The power of continually improving the development practices used withing the organization is hard to appreciate but it is immense. The gains compound over time so the initial benefits are only a glimpse of what can be achieve by continuing to iterate and improve.

Related: Pairwise and Combinatorial Software Testing in Agile Projects - Applying Toyota Kata to Agile Retrospectives - Create a Risk-based Testing Plan With Extra Coverage on Higher Priority Areas

By: John Hunter and Justin Hunter on Dec 15, 2016

Categories: Agile, Software Testing, Testing Strategies

At Hexawise we aim to improve the way software is tested. Achieving that aim requires not only providing our clients with a wonderful software tool (which our customers say we’re succeeding at) but also a commitment from the users of our tool to adopt new ways of thinking about software testing.

We have written previously about our focus on the importance of the values Bill Hunter (our founder's father) to Hexawise. That has led us to constantly focus on how maximize the benefits our customers gain using Hexawise. This focus has led us to realize that our customers that take advantage of the high-touch training services and ongoing expert test design support on demand that we offer often realize unusually large benefits and roll out usage of Hexawise more quickly and broadly than our customers who acquire licenses to Hexawise and try to “get the tool and make it available to the team.”

We are now looking for someone to take on the challenge of helping our clients succeed. The principles behind our decision to put so much focus on helping our customers succeed are obvious to those that understand the thinking of Bill Hunter, W. Edwards Deming, Russel Ackoff etc. but they may seem a bit odd to others. The focus of this senior-level position really is to help our customers improve their software testing results. It isn't just a happy sounding title that has no bearing on what the job actually entails.

The person holding this position will report to the CEO and work with other executives at Hexawise who all share a commitment to delighting our customers and improving the practice of software testing.

Hexawise is an innovative SaaS firm focused on helping large companies use smarter approaches to test their enterprise software systems. Teams using Hexawise get to market faster with higher quality products. We are the world’s leading firm in our niche market and have a growing client base of highly satisfied customers. Since we launched in 2009, we have grown both revenues and profits every year. Hexawise is changing the way that large companies test software. More than 100 Fortune 500 companies and hundreds of other smaller firms use our industry leading software.

Join our journey to transform how companies test their software systems.

Hexawise office

Description: VP of Customer Success

In the Weeks Prior to a Sale Closing

  • Partner with sales representatives to conduct virtual technical presentations and demonstrations of our Hexawise test design solution.

  • Clearly explain the benefits and limitations of combinatorial test design to potential customers using language and concepts relevant to their context by drawing upon your own “been there, done that” experiences of having successfully introduced combinatorial test design methods in multiple similar situations.

  • Identify and assess business and technical requirements, and position Hexawise solutions accordingly.

Immediately Upon a New Sale Closing

  • Assess a new client’s existing testing-related processes, tools, and methods (as well as their organizational structure) in order to provide the client with customized, actionable recommendations about how they can best incorporate Hexawise.

  • Collaborate with client stakeholders to proactively identify potential barriers to successful adoption and put plans in place to mitigate / overcome such barriers.

  • Provide remote, instructor-led training sessions via webinars.

  • Provide multi-day onsite instructor-led training sessions that: cover basic software test design concepts (such as Equivalence Class Partitioning, the definition of Pairwise-Testing coverage, etc.) as well as how to use the specific features of Hexawise.

  • Include industry-specific and customer-specific customized training modules and hands-on test design exercises to help make the sessions relevant to the testers and BA’s who attend the training sessions.

  • Collaborate with new users and help them iterate, improve, and finalize their first few sets of Hexawise-generated software tests.

  • Set rollout and adoption success criteria with clients and put plans in place to help them achieve their goals.

Months After a New Sale Closing

  • Continue to engage with customers onsite and virtually to understand their needs, answer their test design questions, and help them achieve large benefits from test optimization.

  • Monitor usage statistics of Hexawise clients and proactively reach out to clients, as appropriate, to provide proactive assistance at the first sign that they might be facing any potential adoption/rollout challenges.

  • Collaborate with stakeholders and end users at our clients to identify opportunities to improve the features and capabilities of Hexawise and then collaborate with our development team to share that feedback and implement improvements.

Required Skills and Experience

We are looking for a highly-experienced combinatorial test design expert with outstanding analytical and communication skills to provide these high touch on-boarding services and partner with our sales team with prospective clients.

Education and Experience

  • Bachelor’s or technical university degree.

  • Deep experience successfully introducing combinatorial test design methods on multiple different kinds of projects to several different groups of testers.

  • Set rollout and adoption success criteria with multiple teams and put plans in place to achieve them.

  • Minimum 5 years in software testing, preferably at a IT consulting firm or large financial services firm.

Knowledge and Skills

  • Ability to present and demonstrate capabilities of the Hexawise tool, and the additional services we provides to our clients beyond our tool.
  • Exhibit excellent communication and presentation skills, including questioning techniques.
  • Demonstrate passion regarding consulting with customers.
  • Understand how IT and enterprise software is used to address the business and technical needs of customers.
  • Demonstrate hands-on level skills with relevant and/or related software technology domains.
  • Communicate the value of products and solutions in terms of financial return and impact on customer business goals.
  • Possess a solid level of industry acumen; keeping current with software testing trends and able to converse with customers at a detailed level on pertinent issues and challenges.
  • Represents Hexawise knowledgeably, based on a solid understanding of Hexawise’s business direction, portfolio and capabilities
  • Understand the competitive landscape for Hexawise and position Hexawise effectively.
  • A cover letter that describes who you are, what you've done, and why you want to join Hexawise.
  • Ability to work and learn independently and as part of a team
  • Desire to work in a fast-paced, challenging start-up environment

Why join Hexawise?

salary + bonus; medical and dental, 401(k) plans; free parking and very slick Chapel Hill office! Opportunity to experience work with a fast-growing, innovative technology company that is changing the way software is tested.

Key Benefits:

Salary: Negotiable, but minimum of $100,000 + Commissions based upon client license renewals Benefits: Health, dental included, 401k plan Travel: Average of no more than 2-3 days onsite per week Location: Chapel Hill, NC*

*Working from our offices would be highly preferable. We might consider remote working arrangements for an exceptional candidate based in the US.

Apply for the VP of Customer Success position at Hexawise.

By: John Hunter on May 12, 2016

Categories: Hexawise, Career, Software Testing, Lean, Customer Success, Agile

We have thousands of users and we're growing by hundreds of new users a month. We don't have a way to accurately breakdown our users into Agile vs Waterfall users but I know from conversations with Hexawise users that many users are using Hexawise with great results on Agile projects.

Agile projects involve short sprints in which new features are added to existing functionality. These sprints are often a couple weeks long. In such situations, it is important to be able to create tests quickly. Hexawise is extremely good at accomplishing exactly that.

Let me explain by way of an example. A Hexawise user named Sandeep asked how Hexawise could be used to create tests for an insurance ratings engine. I was able to create a sample set of 37 2-way tests within 20 minutes.

Now lets imagine that a sprint creates 2 new features that we'd like to test in combination with the existing test inputs in the existing plan. Let's assume "Feature 1" is a new ability of the application to handle input coming in from three sources: (1) web, (2) agent, and (3) call center. Let's assume "Feature 2" is a new ability of the application to handle Group Discounts. The Group Discount parameter will have 3 categories of values as well: (N/A) for people who aren't able to claim them, "Private company," and "Government / Public."

Added the new features, and created another, completely different set of tests that achieve 100% 2-way coverage. Each value in the new feature is tested in at least one test with every other value in the plan. It took less than 4 minutes to create this new set of tests incorporating the new features. It is an extremely attractive benefit of using Hexawise that is excellent for both Waterfall projects (which inevitably have late-breaking requirements changes) as well as Agile projects (where late-breaking feature additions are expected to happen as part of the process).

You want to keep testing documentation light, you want to minimize the amount of time you spend in selecting and documenting tests, and it is helpful to achieve as much coverage in as little time as possible and minimize the risk that you'll accidentally forget to test things that you meant to test (which can be easier to do if you have light test cases with enough detail in them to maximize your odds of testing the important stuff without accidentally omitting tests). Hexawise helps you achieve all of thise objectives. The example shows, as clearly and concisely as I'm able to explain it, how you can use Hexawise to create a small set of powerful tests within four minutes (from 1.7 trillion possible tests) that are well suited to test new features developed in an Agile project iteration.

 

Related: What is Agile? What is not Agile? - Why isn't Software Testing Performed as Efficiently and Effecively as it could be? - Cem Kaner: Testing Checklists = Good / Testing Scripts = Bad?

By: Justin Hunter on Oct 19, 2012

Categories: Agile, Hexawise tips, Pairwise Software Testing, Software Testing