Welcome to our Blog!

Manual Test Automation - Part 3

In part 2 of this 3 part blog post we reviewed the first 5 suggestions of how you can improve your test automation strategy. In this final part, we conclude this post by reviewing 6 more suggestions that you can look at to start improving your test automation strategy.

The first 5 suggestions to improving your test automation strategy were from part 2 were:

  1. Test Automation must be an integral part of your software development process.

  2. If you are doing Agile or attempting to do Agile, then Test Automation is mandatory.

  3. Test Automation must be executed on a regular and frequent basis.

  4. Do the appropriate Test Automation in the different layers of the application.

  5. Be ready to use the best tool for the type of Test Automation being done.

The remainder of the suggestions are:

6. Don’t get tied to a tool vendor. As you embark on test automation, make sure that you implement test automation methods that allow you to swap a tool out if a better one comes along or if your needs change. If you implement test automation in layers as discussed earlier in this post, and you choose common languages (ex: java, python), then your test automation scripts will be more transportable and you won’t be locked into continuing to use a tool just because you invested so much in test automation with that tool.

I have seen organizations continue to use a tool because they have been using it for so many years and have “so many scripts in the tool”. However, when I ask them, “how often do you run the scripts and how many of them are still good?” they quickly realize that they are not getting the ROI that they should from Test Automation. They are stuck in the Manual Test Automation rat hole!

7. Avoid End to End Test Automation - End to End testing is the most expensive type of testing that an organization can employ and it is usually too late in the process to be beneficial to the organization.

The challenge in “End to End Test Automation” is defining what is “End to End”. Is it from system A to system B or does it mean running a test from the start of a cycle and making sure that the process ends properly through the processing of 10 other systems?

The bigger and real challenge that the majority of organizations face is that they do not have a full test environment that truly represents how production works. Production usually has numerous interfaces to other systems (internal and third-party) and it is just too expensive to replicate the entire production environment.

I recommend avoiding End to End Test Automation as much as you can and if you really must do it, then keep it very minimal and focused on a very specific goal (ex: helping to test that a deployment was done properly in the organization's environment).

8. Scriptless Automation - Don’t believe the hype….. Scriptless automation has been around for decades. In the early days it was the big promise of using a “Record and Playback” tool. It was supposed to make it easy to have your testers just “record” what they would normally test and then just “play it back”. Like anything that sounds too good to be true, record and playback was exactly that. Teams quickly realized that many of these tools had limits and had trouble playing back what was recorded. Teams quickly faced the reality that they spent more time administering the scripts than executing them. These were the early days of Manual Test Automation.

Move the clock forward to the 21st century and while tools have gotten more sophisticated, record and playback remains as fragile as ever. The only reason that some of these tools work better today is not because the tools themselves have become more sophisticated, but because the applications that they are trying to test are developed with better methods and tools.

Furthermore, anyone that uses so called scriptless automation tools, quickly hits limitations. Once people hit these limitations, the next logical move is to want to get access to the code that is generated. If you are going to access the generated code, then why not just cut out the middleman and do real test automation by coding it?

9. Start with a Test Automation Framework - When embarking on a test automation implementation, there is no need to start test automation from scratch. Applications have evolved and many of them have very common functionality that should allow you to find a library of ready to use code functions/snippets that can act as a base for your test automation efforts. This is often referred to as a Test Automation framework. This is one of the key pitches of tool vendors, you get a library of code to start. Aside from tool vendors, the open source community has evolved and matured to the point that some of the open source tools are either as robust or more robust than tools from a vendor. The open source tools also come with libraries of code that has been created by the community at large and is ready to use. These libraries are indispensable as a starting point for any test automation efforts and then your teams will tweak and evolve the framework to match the realities of the applications they are testing in the organization.

10. Test Automation & Business Process Testing- My first encounter with Business Process testing was in 1996 and I believe the tool was called “Certify”. It was produced by a small tool vendor at the time and it promised that you would be able to test your software by using a record and playback tool and just record all your business processes. The tool never caught on at the time and it disappeared but the concept of testing a software through the business processes has continued and is alive and well in today’s software industry.

There is no shortage of tools that make the same promise like the tool in 1996. This is especially true in the packaged software industry. Organizations buy off the shelf packages to run their business and they want to test to make sure that when they configure the package, it maps to their business process.

In this context of packaged software, it is enticing to think that you can just test by running through the business processes. This usually falls apart because most organizations buy packaged software and then customize large portions of the package to the point that there is more customized software running within the package, than the software from the original package. Why buy a package… but that is a topic for another day?

Therefore, if you are an organization that has bought a packaged software and you have kept the customizations to a minimum (I look for not more than 25% of the code base), then maybe Business Process testing could be helpful in these areas. With the remaining 25% of the code base, you should still look at employing some of the other test automation methods I mentioned in this post.

11. Test Automation cannot do it all - As many know when it comes to Test Automation, some things just don’t make sense to automate. Also, there are different types of testing that are required and more suited to help software teams deliver quality software. For example, during a sprint, using manual exploratory testing to help in the early stages of developing a Story is much more productive and cost effective than trying to automate it.

Also, I have found that while Test Automation is vital to an engineering's team ability to deliver quality software, you lose that human touch which brings creativity in testing and in thinking like a human would. End users will always do the unexpected and having some manual exploratory testing as described by James Bach is integral to the process.

 

We think that if you follow these general guidelines, you will be able to implement a test automation strategy that will allow you to be truly agile. This will then allow you to use Continuous Integration strategies which will eventually lead you to the possibility of even doing Continuous Delivery if that is a goal that your organization wants to achieve.

If you would like to discuss how Exempio can help you develop a Test Automation strategy that can work with your software delivery goals, whether you work in Agile or not, please contact us.

Manual Test Automation - Part 2

In part 1 of this 3 part blog post, we reviewed many of the common challenges that organizations face when it comes to developing a test automation strategy. In part 2 we will review 5 suggestions that you can look at to start improving your test automation strategy.

 

What to do?

If you are in this test automation rat hole that we talked about in part 1 of this blog post and you are asking yourself “how do I get out of it?”, here are a few suggestions on where to start.

 

 1. Test Automation must be an integral part of your software development process. In my experience every single project that I have seen which has attempted to “bolt on automation” at the end of a software development process has not gotten the Return on Investment (ROI) that it could get if Test Automation was an integral part of the process.

2. If you are doing Agile or attempting to do Agile, then Test Automation is mandatory. Anyone that is Agile or has attempted to go Agile knows that without Test Automation it is virtually impossible to deliver quality software in the shorter timeframes that are expected. If you are doing Agile or trying to move to Agile, then Test Automation in all of its flavours has to be in the team’s Definition of Done.

3. Test Automation must be executed on a regular and frequent basis. Too many companies spend a lot of money on test automation and then only execute it “when it is needed”. Why would you build automated scripts that can be executed all of the time and only execute it “periodically”? If your test automation scripts are sitting on the shelf, they are collecting dust and becoming obsolete. I have seen too many organizations that “complete” their test automation and the scripts are obsolete the minute they go on the shelf.

You need to setup your build process to automatically execute as much of your automated scripts as possible. The immediate feedback loop is essential to the team and the earlier they get the feedback, the faster they fix issues and save the company money. This feedback loop is part of the DevOPS process that I consider essential if a company is doing Agile or is attempting to go Agile.

4. Do the appropriate Test Automation in the different layers of the application. The internet has many representations of a testing pyramid. What follows is one example of a testing pyramid that I have used in engagements.

 

In essence the pyramid is showing the potential layers of an application, the recommended testing and the amount of testing that should be done in each of these layers.  It is recommended that as much testing be done as close to the actual code as possible.

 

If we look at the pyramid I would expect developers to be writing automated unit tests for the code they are writing. This should be the largest layer of automated testing.

 

Then as the units get used and integrated into other code, the expectation is that automated integration tests be written.

 

In the functional layer, it depends on the application and how it is structured but in essence the expectation is that a higher level of functional testing would be done. Test Automation should be performed in this layer as well and can be complemented with manual testing if required.

 

Finally, you can also do Test Automation in the GUI layer but this should be the smallest amount of testing that is done regardless if it is automated or manual.

 

The key things to remember is that test automation must start with the developers as they write the code and continues in a diminishing rate as you move up the testing pyramid. By running test automation in these various layers, as early as possible and as frequently as possible you are enabling your team to prevent bugs from getting out of control and you actually enable the team to build in quality rather than trying to test it in by “bolting on” Test Automation at the end.

 

5. Be ready to use the best tool for the type of Test Automation being done. Tool vendors like to sell the idea that “one tool can do it all”. While this is a great concept, the reality is that certain tools are better than others in doing different types of test automation. You shouldn’t limit yourself to just one tool, especially if that tool is not delivering what it promised. One tool cannot do it all in my experience.

 

In the final part of this blog post, we will review 6 more suggestions you can use to improve your test automation strategy.

If you would like to discuss how Exempio can help you develop a Test Automation strategy that can work with your software delivery goals, whether you work in Agile or not, please contact us.

Manual Test Automation - Part 1

This 3 part blog post and the title for it is inspired by a colleague who is currently living the manual test automation nightmare on an engagement. He reminded me how common a pattern it is and one that I have seen way too often over various engagements. Based on recent  engagements and stories I hear from other colleagues in the industry, it is clear that it will be a trend that will continue for some time to come..

When people talk about test automation it means different things to different people so let’s start this blog post by looking at the definition of the word automation.

According to Merriam Webster, automation is defined as follows:

  1. the technique of making an apparatus, a process, or a system operate automatically

  2. the state of being operated automatically

  3. automatically controlled operation of an apparatus, process, or system by mechanical or electronic devices that take the place of human labor

The keywords in this definition are “automatically” and “take the place of human labor”. In my opinion, this is a clear and precise definition of what automation is.

When it comes to Test Automation in software, for some reason the definition of automation quickly gets skewed and/or adapted depending on the organization and the people that are implementing and executing software test automation.

Whenever I start an evaluation of a customer's Test Automation efforts, I start by asking one basic question:

“Does your Test Automation execute on a regular basis without someone babysitting the automated scripts?”

 

With many customers the answer is usually; “Well, it is automated and sort of runs on its own but we can explain…”

This generally is the first sign that a customer is caught in the “Manual Test Automation” rat hole. Usually what follows is a whole bunch of “reasons” as to why their test automation needs manual intervention.

Here are but a few of the common patterns that could be an indication that you are running manual test automation:

  • The test environment is not reliable.

  • The test data keeps changing or you need to find data.

  • The scripts are End to End test automation scripts.

  • The End to End environment consists of many systems (Internal and External) that affect the system being automated.

  • The test automation tool is a “scriptless” one.  

  • The solution is very complex.

If this is your reality then you may be stuck in the Manual Test Automation rat hole.

 

Why are you doing Test Automation?

Getting out of the Manual Test Automation rat hole starts by asking yourself, “Why are we doing Test Automation?” Do you have a clear and defined goal of what you expect out of Test Automation? If you cannot answer these questions quickly and with a clear answer, then chances are Test Automation has been implemented for the wrong reasons. Generally when the goal of software test automation is not clear, the implementation is not optimal.

Here is an example of the 3 most common patterns I have seen across engagements. Do you see any that describe your organization?

Reason 1 - Test Automation was implemented to “fix” the problem of bugs/defects slipping into production.

I have already covered the issue of defects/bugs slipping into production in another blog post. Trying to use test automation to “fix” the problem of bugs slipping into production is just another example of that same problem. In summary, the organization should be focusing on trying to avoid having defects/bugs getting created in the first place rather than trying to implement test automation at the end of the development cycle trying to “catch all the bugs” before they make it to production.

Reason 2 - Test Automation is being implemented as the “magic bullet” to fix all of the software delivery issues.

In my experience Test Automation that is “bolted on” after the software is completed, is usually expensive, doesn't provide good test coverage and is being seen as the savior to fix deeper organizational issues.

If test automation was implemented in this context, then it is usually indicative of an organization that:

  • May have a management team that doesn’t fully comprehend software development.

  • Is weak at producing clear requirements for the teams to work with and that show clear Business Value.

  • May have an organizational structure where communication between various teams is not optimal.

  • Has developed/implemented a software system which is not optimal and requires constant “patching”. The technical debt that has been incurred over the years of development is just too great and is not being addressed.

It usually points to an organization whose managers look to test automation to try and save the day rather than deal with these deeper issues,.

Reason 3 - Test Automation is being implemented with the intent to replace manual testing  which is seen as being a problem in the organization. The problems that usually exist in this case are:

  • Manual testing keeps taking longer and longer

  • Manual testing is seen as being ineffective and non comprehensive

  • Manual testing is conducted from a End user perspective only

In this case the organization has yet to realize that building quality software is a team effort and management is still thinking that the responsibility for quality lies solely with one team - the QA/QC team.

In part 2 of this blog post, we will review 5 suggestions you can start with to improve your test automation strategy.

If you would like to discuss how Exempio can help you develop a Test Automation strategy that can work with your software delivery goals, whether you work in Agile or not, please contact us.

Re-Work or New Features, which do you prefer?

Most consulting engagements start with assessments of an organization's current state. Very often, the interview’s that you conduct reveals a lot about the current state of the organization. Once in awhile you come across a statement that an interviewee makes during one of these interviews that make you think. During a company testing assessment, an interviewee said:

“Testing is something everyone wants, as long as it doesn’t cost anything.”

 

Isn’t that the truth! While it seems that everyone understands the need for quality, it is always the first thing that is sacrificed in some organizations.

 

Why is the discussion of software quality so divisive? For some the cost of bad software is obvious and yet for others, their focus is to deliver the software at all costs. Logic would dictate that delivering quality software would be an essential criteria for all organizations.

 

In some organizations that deliver life dependent software, there is no discussion on quality. Quality is top of mind for everyone on the team because everyone knows what is at stake. Once you move beyond these industries, the software landscape is littered with examples of failures due to software problems. Here are just a few examples:

 

  • NIKE Inc (2001) :  Problems with supply-chain management system results in a $100 million loss.

  • AT&T Wireless (2004) : Customer Relations Management (CRM) upgrade lead to $100 million loss in revenue.

  • Knight Capital Trading (2012): Software glitch cost the firm $440 million in 45 minutes using a flawed software algorithm.

 

Not to mention how many software projects just get cancelled and never go live despite hundreds of millions of dollars having been spent to try to deliver the software.

 

Deliver Software Faster - But at What Cost?

One of the common reasons that get cited on why software problems occur is the need to stay ahead of the competition. Software teams are being asked to deliver faster so that businesses can compete. Smartphones and the Internet of Things (IoT) have made that competition even more fierce as software is now in almost every corner of our lives.

 

The proliferation of smartphones has not only increased competition but also made software companies more adventurous when delivering software. The everyday use of smartphones by the general public has trained most people on the need to update their software. Even the most basic user of a smartphone knows about software updates. Software updates can be pushed to millions of users at the push of a button. This has lulled many software companies, regardless of the application, into a sense of comfort by thinking “we can just release a patch if we get it wrong”.

 

On the other hand, companies that develop software also know that whenever there is a problem in production, there are many indirect costs to that problem on top of the direct costs of productivity loss, and the re-work that has to be done to fix the problem. How many companies actually measure the indirect costs? In my experience, not many. Most companies just don’t worry about it because they want to fix it as quickly as possible so that they can work on delivering the next big feature.

 

Building a Culture of Quality

Adding new features to software is usually a fun creative time for a software team. The team wants to develop the best quality software possible. However, the excitement of building new software quickly gets tempered by the reality of having to deliver by a given date.

 

The pressure of a date often leads to a discussion about quality. This conversation occurs daily in many organizations. It goes something like this:

 

Mr. Get it Out: We have to cut the quality on this project because we are running out of time.

 

Ms. Do it Right: Yes but if we cut the quality, then their are risks that it will blow up in production and we will have to fix it later.

 

Mr Get it Out: We just don’t have the time to do it right….

 

Ms. Do it Right: But we have the time to do it over and over again?

 

Inevitably the software gets pushed out at all costs and a problem happens in production which leads to budgets being wasted on re-work and the many indirect costs that are incurred by the company. Some organizations actually track re-work with a budget line called “Break and Fix”. However, the purpose is not to use it to analyze what went wrong and look for ways to improve, but purely as a CAPEX/OPEX budgetary exercise.

 

In many engagements I have advised organizations that “eventually bad software quality will catch up with you”. The costs may not be evident but everyone knows the costs are there. Therefore, rather than looking at software quality as an expense, look at it as an investment.

 

If software quality is done right by using techniques of building in quality rather than trying to test in quality, then the investment will more than pay for itself. You will be able to deliver more features because you will have more capacity from the reduction in re-work. More importantly the company’s reputation will be seen as one of quality and that has been shown to be a differentiator in many of the top software companies.

Build a culture of quality in your organization. Your customers, employees and your bottom line will thank you!

If you want to know more about how to build a culture of quality so that your engineering teams are building in quality rather than struggling to test in quality, please​ ​contact Exempio for a consultation.

Don’t assume a 30% allocation for testing on software budgets.

The software engineering field has changed a lot over the years. There have been many advances in the field in terms of tools used, how teams build and test software, the speed of delivery, etc…

 

For teams that have not yet become a true agile team (every sprint is developed, tested and production ready), one pattern continues to show itself even though this pattern is a carry over from the days of large waterfall projects.

 

The pattern being alluded to is the projection and allocation of budget based on the one third rule. In the days of large waterfall projects, organizations made the assumption that a software budget was allocated one third per major category of work: analysis and design, develop, test. Analysis and design includes the architecture work for the project. This was the rule of thumb that was used to generate High Level Estimates (HLE).

 

This rule of thumb worked well when it was applied evenly to all three categories to generate a HLE. However, once the work actually started, what usually happened was that as the first two categories of work needed more time than estimated, it inevitably came at the expense of testing in an effort to stay on budget.

 

This pattern has caused grief to many testing teams over the years. For some reason the design and analysis or the developers always got more time when they asked for it. The thinking was that without these 2 first categories doing their work, there would be no product to ship. However, for some reason no matter how many changes occurred in the first 2 categories, the testing was usually squeezed to fit in the original rule of thumb. It didn’t matter how complex the testing was, the team was forced into the 30% budget, which always meant that testing had to be reduced. Reducing testing inevitably lead to that vicious cycle of problems in production, which eventually would come back and cost the organization money by having to allocate more and more of future budgets to re-work and corrections, rather than new features.

 

Move the clock forward to today and unfortunately for teams that haven’t become true agile teams, the pattern continues. Organizations think they are Agile but for some reason they are still planning releases to production that are only every 3, 6 or 12 months without any regular deliverables to production. Testing is still thought of as a separate entity within the sprint and the team is usually unbalanced on the number of quality resources. You will usually find a “hardening sprint” or “stabilization phase” at the end of the sprints but in most cases the question of not going beyond the 30% of the budget for testing is still very top of mind in these organizations.

 

If an organization is going to work in this type of environment, then they should be applying the same rules as they used to in the past, an equal amount of time for each major activity: Analysis and Design, Development and Test. However, if an organization wants to remain competitive and be able to release software in a timely fashion, then they need to become a real Agile team that works to build in quality.

 

Agile, Lean and Building in Quality

When a team moves to using Agile and Lean methods, then this team is focused on delivering value to the organization. When delivering value is top of mind for a team, then the amount of budget per category of work is less relevant. The team is focused on delivering valuable working features every sprint which have been prioritized by the product owner who has already made the business case for the feature.

 

It no longer matters how much of the budget goes for each category of work, but rather, how many valuable features can the team deliver for the budget allocated.

 

This also now changes the dynamic of how the teams think of quality. It is no longer just the concern of the testing staff, but rather the team now has ownership of delivering a working feature with high quality. Quality is now everyone’s business, therefore the allocation of a budget by category is no longer really relevant.

 

This new reality has freed up the team to focus on estimating a feature and the work needed to deliver it. The focus is no longer on how much time it should take each category of work to deliver the feature. Yes the team is estimating hours to deliver when breaking down a story into sub-tasks, but the estimate is now a team effort and no longer a siloed effort in which each silo gets allocated limited budget dollars.

 

Agile and Lean methods have helped software teams refocus on what is really important, delivering awesome quality software that delivers value to the organization!

 

If you want to know more about how Agile can help refocus an organization on delivering valuable features and maximizing your budget dollars, please​ ​contact Exempio for a consultation.

Too Many Defects/Bugs, Don’t just look at fixing Testing

In many engagements we come across upper and middle managers that ask us “How do we fix our Testing (QC) process? The team is just not catching the defects”?

We usually start this discussion by asking these managers a question in return; “Why focus on fixing your testing processes first, shouldn’t you first focus on fixing the development process since they write the code?” This usually starts a vigorous discussion about where the problem really lies in the organization, which is exactly the kind of soul searching an organization needs to do when they ask to fix the testing. 

Fix the root of the problem and not just the symptom

The objective in asking this question is to get the organization to think. Why would you spend budget fixing a symptom of a problem. It is not the testing staff that writes the code or writes the story. The process starts with other team members, so the organization needs to do a holistic review of the entire process to really address the issue.

If we take an example from the car manufacturing industry, when a recall occurs, the manufacturers don’t just say “we need to fix how we test the piece being recalled”. Given the direct and indirect costs associated with a recall you can be sure that the manufacturer has spent time reviewing the entire process.

In our opinion, we think software organizations need to do the same thing. Software is at the core of most businesses these days. Having software that is working properly and optimized is essential to staying competitive. So why wouldn’t you do a proper analysis of the entire software process if you have an issue of too many defects?

QA is an Easy Target

Given the nature of the QA role, which is to find problems in other people's work, it is an easy target to shoot at when it comes to bugs. “Why didn’t QA catch it?” is the first question on everybody's mind when a problem occurs.

You won’t hear, “what was the User Story that caused this bug”?

While QA is an easy target, it unfortunately detracts from addressing the real issue, the software engineering process! For software engineering teams to evolve and mature, they need to own the software they deliver as a team.

When a bug hits production, the team should feel the shame

By “owing it”, we mean that they need to feel pride in the software that they deliver. It is not “just software” but rather software that runs a business. When a bug hits production, the team should take ownership of analyzing the bug and seeing what caused it. This should be a regular activity especially in an Agile team that is delivering software in production on a frequent basis (ex: every 2 weeks). Agile teams should be encouraged to include time for defect analysis in their sprints, so that they can get to the root of the problem sooner rather than later. By having defect root cause analysis with every sprint, it ensures that the amount of technical debt in a software does not grow out of control and eventually become the majority of where software engineering dollars are spent.

If you don’t manage technical debt, it will manage you.

How Agile has helped remove the target from QA

When Agile started to become more mainstream about a decade ago, many QA teams felt threatened. Why shouldn’t they feel threatened, Agile was “supposedly” advocating that QA people were not required.

However, if you look closely at Agile, it is actually a huge advocate of building in quality and calls for everyone on the team to own quality. Agile/Scrum calls on the Product Owner to produce clear Stories and Acceptance Criteria, the Dev team to test their code, QA to be involved with the Dev team from the start, and of course have customer involvement whenever possible.

Agile has helped remove the target off of QAs back because it has helped share the responsibility of ensuring that the software delivered is quality software. By sharing the responsibility for quality, it has helped to highlight that there is enough testing to go around. It has helped QA staff to focus on actual testing of the features being delivered, rather than on managing hundreds of defects from a poorly delivered build.

More importantly, Agile has helped an organization look at the entire process of software engineering, rather than just trying to “fix the testing” when defects occur.

If you need help in doing a holistic assessment of your organizations software engineering process, please contact Exempio for a consultation.

Is QA (aka QC) an Impediment?

Is QA (aka QC) seen as an impediment in your organization? If you answered yes to this question, then chances are your organization is in one of two camps:

1) QA is really an impediment

or

2) QA is actually ensuring that your organization is releasing quality software.

QA is really an Impediment

Some organizations still have formal QA departments that execute testing as a separate phase than the development team. While this may be a necessity in some industries due to laws and regulations, for most other organizations where this is not required, it is usually a sign of a QA team that is not ready to change. It is a sign that this QA team is not ready to meet the needs of a software team that is being asked to deliver software more frequently and keep the level of quality high.

Usually this is a sign that some members of this QA team are concerned about the obsolescence of their role as they see signs of the developers being able to do their jobs through automation.

However, if this is the type of team in your organization, then someone needs to make them aware that the move of the majority of software organizations towards Agile is an opportunity rather than a threat.

When we encounter teams like this we ask them; “Why would you prefer to do a job that is very repetitive and sometimes not valued, over a job that would challenge you and would be valued by the organization?” There is a new role for QA in the Agile world, QA teams that are seen as an impediment just need to be shown what these new roles are.

QA is actually keeping the organization humming

With the ever increasing demands to release software more frequently, sometimes QA seems like an impediment but the reality is, it is QA that is actually allowing the team to deliver the software. Deadlines are forever pressuring developers to write code faster and get it out. This constant pressure can cause developers to cut corners in an effort to “just get it out”. In these types of cases, most developers actually find solace when their QA teammate helps remind them the implications of releasing code that’s just not ready. It is in this solace that the appreciation for their QA teammate is highest. At this point the developer and QA actually work together to ensure that a better quality software is released on time.

When this happens it is one example of building in quality rather than trying to test in quality!

In this example the QA team member initially looks like an impediment but he/she is actually trying to ensure that the software is released with quality rather than working in a “Break/Fix” mode.

The concept of building in quality has been around for years. One of the best known advocates of building in quality is Philip Crosby. Mr. Crosby was one of the first people to advocate that if you build something of quality, then Quality is Free! He had many different ways of delivering this message to management but this was the essence of his message.

Most QA people in organizations have this kind of a mind set and try to advocate it but are frequently seen as signs that the QA person is an impediment to just getting it out! Remember that when a QA person provides their feedback on the state of a feature in the software, they just want to deliver the right feature, at the right time with the quality that the end user would expect.

With the move to Agile, the decision to ship has now been moved to being one the Team makes together based on their Definition of Done. Even though the Team now works together, the QA person will still bring this quality mindset to the team, a mindset that should be shared across the Team.

If you are still thinking that despite a QA person’s good intentions, they are still an impediment, think of one more thing.

Delivering quality software means that you incur less Technical Debt, less Technical Debt means that the Team will be able to work on new features in future sprints rather than working on refactoring code and features.

Finally, these higher quality deliverables are essential if one of your goals is Continuous Integration and eventually Continuous Delivery. It will mean that your organization is able to respond quicker to market forces and it will translate into a competitive advantage for your organization. An advantage that will translate to savings and sales for the organization!

If you want to know more about how to ensure that your QA team members can help ensure higher quality deliverables, while meeting the fast moving software delivery train, please contact Exempio for a consultation.

SolutionPartner.rgb Original

Need help optimizing your Atlassian Tools, we can help. Contact Us today.

© 2017, 2016, 2015 Exempio. All Rights Reserved.