It’s Ok to be Agile-ish

In today’s competitive business climate, the “need for speed’ in unparalleled and widely acknowledged.  Many organizations have embraced agile transformations and are moving on to setting up DevOps teams and practices.   Most organizations that have not engaged in an agile transformation have implemented some form of agile methodology or attempted to “go agile” in some way are feeling the competitive pressure to consider it.

The Complexity of Agile Transformation

Agile transformations are complex, costly and time-consuming.  Employees need to take on new roles and learn new ways of working.  This requires training and potentially learning new skill sets.  New teams are formed and they will storm and norm and then hopefully perform.  New infrastructure and tools will be needed and those may require a significant financial investment.

A true agile transformation involves more than implementing new methodologies, processes and roles.  It is based on a culture transformation and changing culture is probably the most difficult initiative an organization will ever undertake.  An agile transformation must be approached from the top down; senior management must not only endorse but more importantly, they must lead by example.

In some verticals, the very nature of the business imposes impediments to agile transformations.  Organizations in regulated industries such as medical devices, pharmaceuticals and utilities find implementing agile methodologies especially challenging given the heavy testing and quality control documentation required of them.  Organizations whose products have safety critical components must adhere to strict quality assurance standards which require allocating time for full, non-risked based testing.  These organizations may find the pace of agile methodologies to be at odds with their quality standards.

Being Agile

With all the complexities and challenges of an agile transformation, the question becomes, is it possible to achieve agility and its benefits without full agile transformation?  Let’s answer the question with a question; what is agile?  Agility is the ability to move, react and change quickly.  It is not only about methodologies and processes but more importantly, it is a philosophy and approach to software development.  Agile philosophy is summed up succinctly in the manifesto and explained in the twelve principles.

The agile approach as well as its methodologies and processes are based on agile philosophy.  Agile is an approach to responding to the unpredictability of developing software by using small, self-managed teams to build software incrementally.  Builds are timeboxed and developed in successive work sequences or iterations.  Most importantly, functionality is delivered by feature and each feature is broken down in its smallest components.

Agility without Agile Transformation

It is definitely possible and a really innovative idea to take an agile approach to software development regardless of the development methodology espoused by the organization.  Any organization can move toward agility by implementing agile practices.  Let’s look at some agile practices that can be integrated into a traditional waterfall systems development lifecycle approach.  Agile practices can be introduced throughout the SDLC, especially in planning, project management and team development.

Let’s start with requirements development.  Break down requirements into the smallest increments possible. This shifts the focus from long term planning to planning for the results that are needed quickly.  Develop and maintain a prioritized backlog of streamlined requirements or user stories which allows for changing priorities easily.  And why not experiment with different estimation techniques to improve estimation accuracy?

Lots of agile practices can be implemented easily into project management. Shorten release cycles as much as is practical. This approach allows time for bug fixes, reduces technical debt, improves quality and increases speed to market.  Apply the concept of developing “Minimally Viable Products”. These are products with just enough features to satisfy requirements.  These products improve speed to market and they are faster to code and test.   Implementing frequent demonstrations of new features provides early feedback.  This means misunderstandings in requirements are caught early, decreasing costly design errors and rework.  Finally, implementing fixed timelines with variable requirements increases flexibility by allowing less critical requirements to be moved to the next release.

Another approach to begin the journey toward agility is to bring agile practices to your teams.  This is a great way to begin a culture shift in a non-threatening way.  Start by implementing daily standup meetings.  This increases transparency and gives everyone a shared understanding of the project status. Use a whiteboard with sticky notes to manage tasks and issues to increase transparency and visibility of the teams’ progress.  Try pair programming and/or pair developers with testers to facilitate the sharing of knowledge and enabling a truer understanding of each other’s roles.  Finally, champion continuous improvement by implementing retrospectives after each release.

The key to agility without an agile transformation lies in implementing the agile practices and processes that not only work within your organization’s culture and constraints but provide value by increasing speed to market and increasing quality.  Many successful organizations are agile-ish and that’s ok.

Advertisement

Meet My Online Personal Holiday Shopping Assistant, Artificial Intelligence

It’s Saturday morning.  I’m enjoying my second cup of coffee and thinking about all the holiday shopping I have not done. “Alexa, how many shopping days left until Christmas?”  “There are 17 days until Christmas.”  Ok, today is the day.  This year, I’ll be staying away from the stores and doing my shopping online.  It’s time to shop, especially if I want to avoid those last-minute overnight shipping charges that may effectively as much as double the cost of the gift.  Yep, that happened last year.

But what to buy?  Would my niece like a designer handbag? Maybe, but I think I may have given her one last year.  How about a Beats headset for my nephew?  I just don’t know.  I decide to take a break from shopping and get another cup of coffee.  Yes, I haven’t even bought one gift and yes, this will be my third cup of coffee.  I get my coffee and decide to quickly check my email before I start.  Yes, I’m postponing the inevitable. 

But what’s this? There’s an email from Lord & Taylor, “THIS Tahari style deserves a second look!”  How does Lord & Taylor know I was looking at party dresses yesterday? I wish I were going to a party.  And here’s an email from NFLShop.com “25% Off Your Favorite Patriot’s Gear”.  What?  How does the NFLShop know that the Pats are my team?

Do I have an online personal shopping assistant?  Well, guess what, yes, I do!  It’s called a recommendation engine, a type of Artificial Intelligence that retailers use to increase sales.  Recommendation engines are systems that use algorithms to predict what customers might be interested in purchasing.  These engines are really the equivalent of the helpful salespeople we meet in brick and mortar stores. 

Salespeople show you the item you request and then, if they are good at their job, they show you additional items that you might like.  For example, when I go into a boutique and try on a pair of designer jeans, the salesperson will bring several tops and jackets into the dressing room for me to try with the jeans.  And yes, I usually wind up purchasing at least one of the tops too.

This same process happens when you shop online.  I’m sure you’ve all “met” these helpful, artificially intelligent, online salespeople.   When you select a product, you’ll often get an additional selection of products with the message “Customer’s who purchased (insert what you are purchasing) also purchased….”. 

Have you ever wondered how those additional products are chosen?  Just as the salespeople in the stores make intelligent decisions as to what else you might purchase, recommendations engines do the same thing, only their “intelligence” is artificial; their intelligence is “learned” by the data fed into its algorithms. 

Recommendation engines are fed data based on three models:  collaborative filtering, content-based filtering and hybrid recommendation systems.  Collaborative filtering applications are fed data about potential customers current behaviors or purchases through which the algorithm predicts future behaviors or purchases.  In this model, I will be offered items that a chic, fashionista like me might want, perhaps a pair of Jimmy Choo stilettos?  I guess it doesn’t yet realize I’ve changed my designer tastes to handbags recently. 

In content-based filtering, the algorithm uses keywords to understand the item under consideration for purchase and suggests additional items.  I recently purchased a pair of Brooks Ghost 10 running shoes as a gift for a friend.  The recommendation engine offered me an ultraviolet flashlight and other ghost-hunting equipment.  Not quite what I was expecting.

Fear not, hybrid recommendation systems combine the best of both models.  Hybrid recommendation systems evaluate collaborative data and content data separately and then combine it for the recommendation.  This makes my personal shopping assistant more effective than ever before!

Oh, that reminds me; I’m supposed to be holiday shopping this morning.  With my personal online shopping assistant making lots of great recommendations, my holiday shopping will be done in no time!  Enjoy your shopping and have a wonderful holiday season!

Don’t Miss How Did I Miss that Bug

How Did I Miss That Bug: Overcome Cognitive Bias In Testing

How many bugs have you, or your teams, missed that were clearly easy to spot?   Testers approach all phases of testing hampered by their own biases in what to look for, how to go about setting up and executing tests, and interpreting the results.  Understanding your biases, preconceived notions and ability to focus your attention are the keys to managing cognitive bias in test design, test execution and defect detection. 

This webinar will provide an understanding of how testers’ mindsets and cognitive biases influence their testing.  Using principles from the social sciences such as Kahneman’s framework for critical thinking and Chabris and Simons’ findings on attention, perception and memory, this presentation will demonstrate that you aren’t as smart as you think you are.  Gerie will show how to use this information to understand the impact of cognitive bias on testing and to improve your individual and test team results.  Gerie will discuss the balance between functional and exploratory testing; you will learn how to use each effectively.  Finally, Gerie will provide tips for managing your biases and focusing your attention in the right places throughout the test process so you won’t miss that obvious bug.

Do you want to learn more?  Please join my webinar with Eurostar on August 29th at 9 am est

https://huddle.eurostarsoftwaretesting.com/resources/people-skills/i-miss-bug-overcome-cognitive-bias-testing/

 

Continuous Testing: An Interview with Gerie Owen

Continuous testing is the process of executing automated tests as part of the software delivery pipeline. It provides rapid feedback on the business risks associated with a software release candidate.

Clearly, continuous testing requires automation, however, it encompasses much more. It is an approach to managing risk by focusing on not only on improving testing efficiency but more importantly, increasing the effectiveness of our test processes.

Continuous testing requires not only continuous risk analysis and process improvement and implementation of automated these through the entire software development process; but also, developing a culture in which the entire team is responsible for quality.

Listen in on my podcast with Tom Cagley to learn more.

The Testing Profession…A Brave New World

Most professions change and evolve and yes, some even die. Our testing profession has undergone so much change and much of it is truly disruptive. Many of the changes have caused us, as testers, to question whether or not our profession has ceased to exist. The good news is that as long as there is technology in our world, it will need testing. And as history shows, technology will grow and change in ways we cannot even imagine.
The pace at which technology, and approaches to its development, will continue to increase. New worlds will be spawned continually, and sometimes disruptively. Our role and our responsibilities as testers will continue to evolve and change and we will be challenged to expand our knowledge and skill sets in order to contribute and grow in this fast-paced climate.
The World Quality Report 2016-17, https://www.capgemini.com/thought-leadership/world-quality-report-2016-17, discussed current trends in quality assurance and testing. Among those were Digital Transformation, the Internet of Things, Security Testing and Agile and DevOps. Let’s review these trend-setting brave new worlds and the skills we will need to embrace them.
Digital Transformation
The majority of consumers today have embraced technology and as a result they expect to transact with organizations through multiple channels. Therefore, digital transformation is not only inevitable, but imperative for all organizations. More importantly, customers not only expect a seamless experience across all digital channels; but also, they demand applications that are intuitive, easy to navigate and perform consistently. As testers in a digital transformation, our role goes beyond testing. We are the customers advocates and the guardians of the organizations’ reputations.
Internet of Things
We all now live in the Internet of Things. From smart phones to voice controlled personal assistants, we are all interconnected to “things”. Comprehensive testing in this brave new world involves not only testing the devices, platforms, browsers and the various combinations thereof, the applications themselves as well as their integrations and, perhaps most importantly, the interaction between the device and the human being. Risk analysis is critical as the number of test scenarios expands exponentially, given all the types of functional and non-functional testing that is required. As testers, we are challenged to employ our skills in, mobile testing, usability testing and as well as our understanding of customer experience.
Security Testing
We are all responsible for security testing. Security is an overarching concern in all of our brave new worlds, most especially in mobile, the internet of things and digital transformations. Security breaches can be more far-reaching and have more severe consequences than almost any other type of production failure. Security testing starts during design; as threats and vulnerabilities and defects often require design changes. Security testing invites testers to reverse their thinking; it’s about proving that the application doesn’t have threats and vulnerabilities as opposed to finding bugs.
Agile and DevOps
The competitive climate in almost all industries dictates a need for increased speed of delivery and information technology departments have responded by moving to Agile and DevOps methodologies. Since quality and speed of delivery are opposing goals, testers must find new approaches in order to streamline testing, maximizing both effectiveness and efficiency. Testers are challenged to find their role on Agile and DevOps teams. The team approach in these methodologies relies on all team members taking responsibility for testing; however, the tester must assume the role of championing quality through the development process.
In Agile’s test driven development, testers pair with developers in order to create the test cases prior to development. In addition to our test automation tools, testers have the opportunity to become creative by using BDD, Behavior Driven Development, mind maps and model-based tests. Finally, the importance of colocation of Agile teams create a challenge for our Test Centers of Excellence that rely on distributed test teams.
DevOps, with its focus on continuous integration and even continuous delivery, poses the same challenges to streamline testing, yet increased. DevOps is a mindset that focuses on communication and collaboration among developers, operations specialists and quality assurance teams, so testers must embrace collaboration while at the same time ensuring that testing is done throughout the continuous integration cycle.
Clearly, testing is in a state of transition. Testers must not only learn new technical skills, develop streamlined testing approaches, as well as become the advocate for the customer; but also, adapt to and find their place in Agile and DevOps methodologies. And yes, that’s a huge challenge!
I’m sure you all have heard, at least once, that testing is dead. However, according to Techwell’s inaugural survey, The State of the Software Testing Profession 2015-2016, https://www.stickyminds.com/state-software-testing-profession-results-2015-2016 , 84% of survey respondents disagreed. No matter what technology or development methodology is used to develop software, the software will need to be tested. Testing won’t die! How we test, when we test and what tools we use and even whose role it is to test will continue to evolve and change. Testers, welcome to the Brave New World of Testing.

DevOps Still Has Room for Testing

You wouldn’t think that Boise, Idaho would be a hotbed of technology.  However, with the headquarters of HP Printers, a large Micron Technology facility, a number of technology oriented financial institutions, and even a few dot-coms, it combines a high quality of life with a bent toward technology jobs.

Boise held its first DevOps Days conference in October, and almost two hundred practitioners showed up to interact and learn more about how they can work with devops concepts.  I had the privilege of being invited to speak, and over the course of two days, interacted with many of those practitioners.

I learned that even in Boise there are a large number of IT professionals that are highly interested in bringing devops concepts into their organizations.  They work for technology companies, banks, government, and even startups.  They trended young and casual, as you might expect in a city with two major universities.

There were technical speakers from the likes of Docker, Chef, and JFrog, who explained how to use their respective tools within a devops environment.  Some of these presentations were in the weeds, focusing on what new features in containers and artifact factories brought to bear on creating better containerized software.  In places, they acknowledged that they contradicted each other, especially in places where their respective tools offered significant features.

Speakers from JPL and Sonatype discussed how to set up working environments for continuous integration and continuous delivery.  The focus was on getting the right tools and workflow in place, and trusting that the software pipeline will fill up at some point

DevOps Still About the Plumbing

One impression that stood out was that virtually all of the practitioners were still in the very early stages of a devops transformation, seeking the right way to configure their devops infrastructure.  Specifically, they were still looking for a continuous integration/continuous deployment (CI/CD) solution that actually worked for them and delivered on the promise of devops.  That involves specific tools, and how those tools work together in designing the software process workflow.

Testing remains a big dark hole in devops.  The speaker from JPL, Dan Isla, was asked how testing was accomplished.  He gave a weak laugh, and said that some of the developers did unit testing, but their focus was on getting code deployed quickly, and if necessarily failing quickly.

To most of us, failing in production is simply failing.  And in a mission-critical environment such as JPL and NASA, failure often means the loss of millions of dollars and years of time.  In other organizations, it could mean the loss of business and revenue.  Yet many devops professionals seem to lack the appreciation of the need for testing, or don’t believe it’s critical in a devops shop because they can fix and redeploy quickly.  That approach needs to change.

There seems to be a lot of opportunity for solid testing in the process, as long as that testing can be done in a CI/CD environment.  There is the future challenge for testing.  There has to be a major role in ensuring that devops delivers truly working software that can withstand actual production use.  It’s simply not there yet, and testers have to play a key role in getting it there.  Today, practitioners are largely aren’t thinking about how to test either the infrastructure or the software that uses that infrastructure.

It is largely a new language and workflow for testers, and the learning curve may be steep for some.  Some testers will be left behind by the new approaches to development and delivery, and may not fully appreciate the role of the devops workflow.

And to be fair, most organizations are not yet in the position to create containerized software.  There is a lot of discussion surrounding the use of Docker and similar tools, but few seem to be actually doing it.  It’s not clear that containers are necessarily the best way to build software into a known production environment, and testers need to weigh in on that, too.

Most of the devops vendors are offering very technical solutions to very specific environments.  But software development and delivery is a very unique process; every organization has its quirks.  My impression was that practitioners are confused on the approach they should be using, and how to integrate a devops process into their existing workflow.

This is an excellent time for testers to assert a role in devops.  That role might be as test consultants, providing testing standards and objectives to teams, or it might be setting up test automation environments as part of the workflow.  Most devops thought leaders admit that devops is a cultural rather than technical challenge, and testing can be made a part of that cultural shift.

Is Testing a Profession?

Testing is a real profession, but it’s undergone significant upheaval and change in recent years.  Don’t expect that to change in the future.  If you like rapid change and a fresh challenge with every project, testing can be a challenging and exciting career.

Just as programming offers a wide range of career choices, so does testing.  You can do anything from traditional UI testing to working with medical devices or even wearable devices.  Depending on your skills, inclinations, and yes, job opportunities, there are many different directions to take your career in testing.  Whether or not it can become a true career depends on your ability to reinvent yourself on a regular basis.

The profession of testing, as well as its knowledge and skills requirements, has changed substantially in the last decade.  First, it has diversified.  As testers, we understand the language of requirements, test plans, test scripts, and defects.  We create automation frameworks and run performance tests.  Yet, the testing world has become increasingly more complex and fluid.

The testing profession offers so many new areas of specialization.  Big data,  security,  IoT,  wearables,  mobile and embedded as well as user experience, customer experience and even machine learning and artificial intelligence are just a few of the possibilities.  And there are certifications in many of these areas.

Testers don’t necessarily have to choose a specialization; in fact, because computing changes so rapidly, a single specialization may be too limiting to give you the breadth of experiences you need over a long career. However, there are some trends in technology and methodology which all testers much embrace in order to build a career in testing.

First, are the agile methodologies, which have largely become the mainstream of development methodologies.  In agile teams, the testers take on multiple roles, the most important of which is championing quality and helping the team to see quality as the responsibility of every team member.  Testers also play a critical role in test-driven development (TDD) where the tests are created first and code is developed to pass the test. Testers also have the opportunity to pair with developers in testing as the code is being developed.

DevOps is another trend that testers can’t ignore and must contribute.  DevOps principles are based on breaking down barriers between development, testing, preproduction, and operations, in order to get software into users’ hands as quickly as possible, and to find faults and fix them in real time.  In DevOps, testers’ primary responsibility is ensuring the quality process.

Work on your communications skills

Communication and collaboration skills have never been more important.  Testers are often the ones delivering the bad news, and have to do so in a way that doesn’t lay blame or responsibility.  Further, they typically work as part of a larger team, and have to establish respect while advocating sometimes-unpopular positions.

Although testing is still a viable profession, there can be disadvantages to a testing career.  While most organizations need developers and IT people, some methodologies have been trending away from formal testing as practiced in many waterfall-based methodologies.  In particular, agile and DevOps are focused primarily on automated build and delivery chains, so automation skills are a requirement.  Wearables, IoT, and other devices may require knowledge of electronics and hardware-in-the-loop testing.

Testing in general is no longer the gateway through which an application has to pass in order to be successively deployed.  Companies have become far more willing to deploy software that may fail, as long as it does so fast.  Yes, users may face obstacles, but companies figure (often correctly) that users will help them tune their applications for more widespread use.

The upshot is that testing has become much more ambiguous than it has been in the past.  To effectively pursue a career in testing, it is critical to develop skills related to defining and executing tests earlier and faster, and to be more attuned to the ambiguity of software releases and feedback.

Testers must manage their own careers by getting the experience and training they need to thrive and grow in the testing profession.  Creative approaches for obtaining some of these experiences include volunteering for other projects that may be using innovative new techniques, or by participating in, or even organizing, corporate learning activities such as workshops and lunch and learn functions. Testers will have to invest in their own careers, perhaps by taking agile or DevOps courses and certifications, or by working on independent open source projects.

Finally, to create a career in testing it is important to recognize testing as a profession.  Get involved in the testing community through conferences, online groups and meetups.  These are not only great learning opportunities, but they offer testers a chance to mentor each other and to build recognition of testing as a profession.

Check out my upcoming Webinar

Gerie Owen to Present Webinar
Webinar: How Did I Miss That Bug? Managing Cognitive Bias in Testing
How many bugs have you — or your teams — missed that were clearly easy to spot?
Testers approach all phases of testing hampered by their own biases in what to look for, how to set up and execute tests, and how best to interpret the results. Understanding how your biases, preconceived notions, and ability to focus your attention are the keys to managing cognitive bias in test design, test execution, and defect detection.
Join the webinar
In this July 11 webinar at 11am PDT, Gerie Owen will give testers and test managers an understanding of how testers’ mindsets and cognitive biases influence their testing. With over 25 years of test-driven development experience to tap into, Gerie will provide tips for managing your biases and focusing your attention in the right places throughout the test process so you won’t miss that obvious bug.
This webinar presentation uses principles from the social sciences — such as Kahneman’s framework for critical thinking and Chabris and Simons’ findings on attention, perception, and memory — and short, enjoyable exercises on preconceived notions. With Gerie’s help, improve your individual and test team results.
What the participants will learn:
Why we aren’t as smart as we think, i.e., how we develop biases and preconceived notions.
How biases and preconceived notions negatively impact our approach to testing throughout the test process.
How to design a test approach to effectively manage the way we think during the test process.
Ways managers can increase their teams’ effectiveness by improving their focus.
Tips for finding the obvious bugs you are missing.
Main Message:
Become a top-performing tester by understanding your biases. With Gerie Owen’s tips, you’ll learn the keys to great test design, test execution, and effective defect detection. Register today!

Understanding How Assistive Technologies Make Products Accessible

 

Hi Testers, welcome to the brave new world of assistive technology.  Assistive technology is a term that refers to all types of technological devices that enhance the quality of life and improve independent function for people living with disabilities.  Assistive technology is available for people with visual, hearing, mobility disabilities as well as cognitive impairments.  Assistive technologies range from low-tech devices that assist with daily living activities such as eating or showering to high-tech readers for the blind and listening devices for the deaf. 

How does this fit into the category of software or device testing?  In many cases, testers are responsible for accessibility testing of new products, including web applications, personal fitness devices, and hardware/software products for finance, transportation, and other areas.  Knowing how the assistive devices work, and understanding how they are tested, is an essential part of understanding the requirements of accessibility.

My friend Max introduced me to his world of assistive technologies when I visited him recently.  He is legally blind and has an impressive array of assistive technologies in home office.  His devices range from lighted magnifying glasses to the Optelec Reader and Zoomtext.  The Optelec reader will not only magnify pages of magazines but also scan and read them aloud.  Zoomtext is a software program that will enlarge, enhance and read aloud everything on a computer screen.  Using Zoomtext, Max is currently writing a book.  

Max is an avid reader and when the Library of Congress digitized books, Max was a beta tester for the various reading devices.  Max uses his phone to dial into the National Federation for the Blind’s Newsline to keep up with current events.  He has access to thousands of newspapers and he can listen to articles of his choice.  I was so impressed with how much these technologies improved Max’s quality of life.

After my assistive technologies demo, as a tester, of course I became interested in how and who would test these devices and software programs.  My initial thoughts centered on accessibility testers who can apply their knowledge of specialized accessibility test techniques that they use to determine levels of usability by people with disabilities.  Accessibility testing is critical for websites and software programs, yet actually testing assistive devices requires something more.  More than any other type of device or software, assistive devices and software must be designed and tested based on the needs of the user.

Since usability testing is so critical for assistive technology, I realized that human experience testing so as applicable here as it is to wearables.  I recently developed a framework for human experience testing that I’ve presented at several testing conferences.  Human experience testing goes beyond usability in scope, depth and approach.  The closer the device becomes to the human, the more important “Human” Testing becomes. 

The Human Experience testing framework uses personas and user value stories to test the interaction between the person and the device.  Personas are detailed descriptions of the archetypical users who represent the needs and motivations of the user group.  They represent the motivations, values, expectations and goals for their interaction with the device.  User Value stories describe the ways in which users interact with the device.  They are based on how the users go about their daily lives.  Since people with disabilities depend on assistive technologies in the daily lives, human experience testing is critical.

The use of personas in assistive technology design is happening today. The Assistive Technology Industry Association (ATIA) is currently working with Jeff Higginbotham, PhD,  professor at the University of Buffalo on promoting persona-based design for assistive technologies and Microsoft is pioneering the concept.  So it follows that testing should involve the human experience.

I believe that testing assistive technology requires not only special test techniques, but also, special testers.   The initial testing of the prototypes and human experience testing can be done by accessibility testers; however, the final user experience testing should be done by those for whom the device is designed; those who will actually use the device in their daily lives.

Testing assistive technology is not only challenging and fascinating, but also, it is rewarding on many levels.  As my friend Max told when he introduced me to his assistive technologies, “Assistive technology makes life a little bit easier.”

To what extent should testers and QA engineers be involved in software design?

Traditionally testers and QA engineers have had minimal involvement with software design.  Design has been the role of the software architect, or team lead, for many years.  Depending on the team, input from testers at this stage of the software development lifecycle isn’t always valued.

But in some circumstances that is changing.  In particular, testers have a real contribution to make when one of the product goals is “design to test”.  Architects who recognize that contributions can come from a variety of sources are soliciting testing feedback when creating an overall design.

And testers have even more design contributions in Agile projects, especially when using Test-Driven Development (TDD).  Testers typically have a more complete picture of user needs, based on their in-depth understand of user stories and interactions with the Product Owner.

Because design is something that grows with the application in Agile, testers can always look at what the developers are doing.  If the team starts letting the design get complex, or difficult to test, it’s time to have a talk with the developers about making the design more straightforward.  It may require a hardening sprint or two, but it will keep the debt down.

For testers, here are some of the things you might consider as you share your expertise with architects and developers.

Do:

• Provide feedback on design for testability. You don’t want to accumulate testing debt.
• Get deeply involved in TDD projects. This is your area of expertise.
• Provide feedback on design decisions during an Agile project.

Don’t:

• Attempt to give advice outside of your area of expertise.
• Reject feedback on your design ideas. Everyone has something to contribute.