QA KPI Metrics

I’ve been talking at several conferences and one of the questions that keep coming back when I talk about QA Automation are the metrics, specifically the QA KPI metrics. Everyone is interested in the kind of metrics to look at when measuring automation.

What kind of metrics are you considering in your automation? Let discuss a little bit about QA KPI metrics.

In general KPI metrics software quality is defined as followed:

• • • the number of defects,
    • the number of blast rate,
    • or the number of failed tests cases,
    • the code coverage

Although this above information gives some important data, all related to testing activity, my approach to quality KPI really depends on the following questions:

• • Who is looking for the data?
  • Who is looking at the data?
  • What is the data going to be used for?
  • How are you able to make a decision about the data?

Based on the answers to each above question, I create a dashboard to make data accessible to everyone in the organization.

When talking about who? –

From my personal experience, there are three groups of people who are interested in the data for software quality to determine the health of the application that is under test.

The first group, usually the tester, is actually the one doing the testing work; the QA tester, the QA engineer, and the Quality engineer.

They just want to determine where they are at during the testing so they can see the progress and have a great confidence level about the testing.

The second group, usually the middle management, the direct team member manager (software quality manager or Quality leader, Dev manager, DevOps manager or Ops manager), and anybody that is supporting the application and managing a team that is supporting the application.

This second group is more interested in the progress of their application under test.

Finally, the third group, the upper management (your C suite, your VP of Technology, VP of product, CTO, CIO, and CISSO) are the one that really needs to look at the high level on a high-level view of the data.

This third group needs to know the following:

How is the application going? Is it healthy? can I sleep better at night and know that my application is bug-free. That nothing is going to happen in production,

especially around this time, the holiday, what is the performance of my application?

So, each of these groups mentioned above has different interests in the application. They have different interests in the quality of the application.

They also have different interests in the data they’re looking at.

So, you can’t mash up every data and give it to them.

You have to make sure that at each level, you provide some type of data that is really useful, usable for them. Obviously, if you are the VP of product and you want to dive in and really look at the bugs, you can feel free to do that, or if you are a Dev manager and you want to look at the bugs report you are free to do that as well. So that’s how I usually try to frame my quality KPI metrics. I also like to consider a different approach and promote the following as part of your Quality KPI metrics

• • Better Visibility
  • Clear transparency into the data
  • Direct accountability
  • Guidance for continuous improvement

For each audience member here are the possible QA KPI metrics to consider and the threshold to evaluate:

 For the QA team member, consider creating an internal QA scorecard

• • • Active defects(new, open or fixed) — trending low
    • Authored Test cases: Number of test cases created – Threshold should be 1-1 to the number of user’s stories or 1-2
    • Covered Requirements: Percentage of test cases mapped to requirements – Threshold 80-100%
    • Defect fixed per day /per week: How fast is development fixing bug
    • Passed Requirements: Number of test cases passed for a requirement
    • Passed Tests: 80% threshold
    • Rejected Defects:  No more than 5%
    • Reviewed Requirements:  100% threshold
    • Critical Defects:  should not exceed 10

For Team Manager, the metrics should provide current progress so consider the following KPI metrics:

• • • # USERS STORIES
    • #USERS STORIES PASSED
    • % of Test Passed
    • #Number of test cases
    • #Number of Passed
    • #Number of Failed
    • #Number of Test cases not Executed
    • Defects Metrics
    • #Open Defects
    • #CLosed Defects

      For the Leadership Team, the metrics should allow for a quick decision at first glance, so consider the following KPI metrics:

• • • 80 % of test cases PASSED
    • % of user stories PASSED
    • Number of P1 and P2 bugs
    • Escape bugs in production
    • Product quality health (red, yellow or green)

We also define the product quality health; I have defined a KPI framework to determine the quality of your product using the following data and threshold to evaluate.

%Passed Test cases

% Escape bugs aka bugs found in production

% Passed User Stories (Pass Rate to stories Ratios).

% PASSED TEST CASES> 80% – GREEN EXCELLENT

% PASSED TEST CASES < 80 – 50% –YELLOW Satisfactory

% PASSED TEST CASES < 50% – RED Unsatisfactory

%Escape Bugs = #escape bugs / #functional bugs

% Escape bugs < 10 % – GREEN EXCELLENT

% Escape bugs > 10 -30 % – YELLOW – Satisfactory

% Escape bugs > 30 % – RED – Unsatisfactory

In summary, it’s important to determine who you deliver this KPI to; in order to make the best decision for your team. In essence to determine the quality and give you that high level of confidence that software has the best quality.

Comment below and tell me about how you determine KPI in your organization or what kind of challenges are you facing in terms of KPI metrics.

Impact of Artificial Intelligence on QA Automation

By Lisette Zounon, CSM-CSP, CAL1, DTM 

In the past ten years, most QA automation tools provide QA engineer opportunities to create test automation, but we still lack in some areas such as efficiency in execution, reusability of the test cases, and fast update. Manual testing may take a long time whenever a break in the script occurs. QA automation has room for improvement to enable fast error detection. At its core, Machine Learning is a pattern-recognition technology—it uses patterns identified by your machine learning algorithms to predict future trends.

Artificial intelligence is becoming very crucial in information technology. In the last few years, software automation has been experimenting with AI and machine learning. Below we are going to detail some of the benefits of AI-based tools.

1. Determine the benefits of using AI-based tool
   • Visual validation testing

Visual testing is about verifying if the visual aspects of the application seem appropriate to the end-users. Visual bugs are usually rendering issues.  Because of the accuracy of AI-powered automated visual testing, they can be deployed in more than just functional and visual testing. AI-powered visual testing tools are crucial to validating any application that requires a constant change in content and format.

• Test APIs

Artificial intelligence-enabled API testing provides a leap forward in productivity and efficiency. You can capture all the steps in one set. With AI-enabled API, you can define something once and lock it in in a smart test template and share that template across a large body of testers. It helps to manage and understand the full API inventory. Users can benefit by adding machine learning to automate API test creation by bringing consistency and coverage to their efforts.

• Self – healing of automated tests

There is a need for a system to detect break and fix automatically without human intervention. The automated test requires a lot of maintenance when you have an application that changes frequently. Self-healing or auto-healing is used to help adapt to any minor changes, so the tests keep working. Every time, tests are run, it interacts with an element; it collects element attributes that it uses to find the element next time and track change over time. The test could track many attributes such as text, CSS Classes, data, and other information like location and size on the page. Any test step that interacts with an element on the page can be auto healed.

AI-enabled automation to provide some more intangible value to QA testers. AI allows your tests to be reliable because your tests can now adapt to develop changes. AI is not here to take over quality assurance, but it is more to allow the quality engineer to become more productive and focus on what QA does best.

Some of the advantages, AI have proven are:

• Improve test cases creation
• Improve quality gates
• spot duplicate errors and new errors in code changes
• Create more reliable automated tests

I have the opportunity to experience and use QA systems with functional testing and with load testing, both leveraging artificial intelligence. Below is a summary of one case study among many of using AI-based automation tool.

2. Summary of the successful case study of using AI-based tool

Problem

This high performing agile team has been working together over 10 months on building a new site with various services for the customers. They had met the initial deadline after all the hard work to make the customers happy. But now they have a huge backlog of features that the customer expects them to deliver in the next six months. The team concern is mostly around ensuring the new features, new code release does not break existing functionalities that the customers have come accustomed to enjoying. The only QA team member in this agile team has created over 1100 test cases to successfully tests all the features of this site. QA team member usually takes 2-4 days, three days on average to run all the regression test cases after each code release in one environment. The goal is to ensure fast delivery, fast error detection from one environment to another, and finally fast feedback from the happy customers.

Solution

QA Leadership took charge of this problem and went out to look for a tool that can help solve this challenge and ensure fast delivery, fast error detection, and fast feedback. We found an AI-based tool that the QA team member can leverage to solve this challenge. After speaking with the agile team and demoing this tool for them, they all got excited and plan time in their sprint cycle for QA to automate the regression suite. The QA analyst with no prior coding experience starts creating test cases in the AI-based tool with training. It took about 3-4 weeks for all these efforts in automating all the 1100 manual test cases.

Result

The execution of the 1100 automated test cases takes about 30 min to run successfully in one environment. These test cases are easily executed in another environment from QA to staging to production environments. QA team is now focused on sprint work items testing and can leverage the regression suite testing to quickly execute test cases. The team is able to leverage the test case automation in the CI/CD environment. This enables fast delivery of the new features, fast error detection and fast feedback to customers. The team now has a consistent execution of the same test cases in all environments.

3. Return on Investment on the project and team happiness

The return on investment ROI on using AI-based tools in your QA automation is huge for your project and your team. Here are few that we know and have experienced:

1. 1. 1. 1. Embrace lifelong learning mindset
         2. High-quality software
         3. High-quality software
         4. Fast feedback loop to the customer
         5. Fast response to the issue
         6. Cross-functional team involvement
         7. Increase team confidence
         8. QA becomes a fun activity and no longer a bottleneck
         9. Team happiness increase and better team engagement
         10. Great teamwork and collaboration

References

https://support.smartbear.com/testcomplete/docs/testing-with/running/self-healing-tests.html

https://techwireasia.com/2019/07/what-is-self-healing-automation-and-why-is-it-important-to-devops/

https://applitools.com/blog/visual-testing/

https://www.parasoft.com/to-make-api-testing-easier-add-machine-learning-to-your-ai/

https://techbeacon.com/app-dev-testing/how-ai-changing-test-automation-5-examples

In the past two parts of our QA automation strategy discussion, we explained organization tradeoff, technology stack, defining your vision, and determining your tools. In this last part, we will be focusing on defining your automation ROI and implementation of test cases.

It is crucial to define your automation ROI to build a positive case for transitioning your team to QA automation.

Transitioning to automation is a large investment, and to effectively achieve it, you will need a set of metrics and considerations to calculate your ROI. These may include:

Determine business requirements/user stories to be implemented
Understand test cases for each requirement
Determine percentage of test cases that can be automated
Asses test case complexity
Measure test cases from prior requirements needed for regression testing
Calculate total number of configurations that need to be tested.

The calculation of your ROI is based on the investments that you are making when building your automation sets. This will be a long process, but you might want to consider a proof of concept (POC) experimentation phase to prove a minimum ROI. This will build your team confidence in the success of this endeavor. Consider the followings in your ROI calculation:

The capability and knowledge of each automation engineer. How long it might take different engineers to understand and script test cases can vary. It is good to define an average when considering the time and the complexity of the test cases.
Define a baseline for how long it takes to execute your test cases manually
Once you define the set of test cases, your simple ROI can be calculated with the following: ROI = Gains – Investments / Investments

It is usually recommended to start your automation build up with your regression test cases. Regression testing is the process of running older tests to ensure that new updates to a piece of software have not introduced or re-introduced previously eradicated bugs. For this reason, regression is important to the success of your software delivery. It makes sense to focus your automation on your regression suites, as those repeatable test cases that you need to run all the time. You usually know how long they will take you to execute them successfully. Spend your time automating those first. Then, your gain will be calculated by how long it takes to run your automation for that suite. For example, if your regressions suites take you 16 hours manually to run successfully, and your successful automation now lasts 16 min. But what if it took your QA engineer about 60 hours to implement the automation? Then, your ROI is about 73%.

Secondly, you have to consider calculating your ROI for new test cases. For new test cases, you have to ensure that the QA automation engineer has a great understanding of the feature in the test to build out the automation immediately. In this case, you may not have any baseline of manual test cases to calculate any gain. Your gain is the speed of adding these new sets to your regression suites. I usually don’t encourage this for a new team experimenting with QA automation, but for mature teams, this may work after you have successfully tackled all of your regression test cases, sanity tests, and smoke tests.

Most of the organizations that transition into QA automation usually set a grand vision and goal for automation. It is important to have a goal the team can work toward. Manual testing will continue to occur and should be your first attempt in testing for your application, though some scenarios might not be able to be automated. Therefore, an automation goal of 60 – 80% is recommended.

Another consideration is test case complexity. It can be discouraging to focus on more complex test cases at the beginning. It is not recommended to explore automation with test cases that are manually complex first. They are prone to error and require a huge amount of maintenance for the future.

With automation, some test cases can be reusable. Therefore, the ROI can increase as your suites grow since you will be using some of your old test cases to execute new ones.

Now consider the cross-browser testing when you have multiple platforms to test one. With an automation set, you will be able to run your tests on many platforms in parallel. There can also be a massive gain to coordinating all your tests (smoke, sanity, manual, automated, and load testing) in parallel, increasing your ROI as well.

Defining your QA automation strategy is an integral part of your automation transition. This process requires various mindset shifts, practices, and considerations into organization tradeoffs, your technology stack, their automation vision, your tools, your ROI, and finally, your implementation. Calculating your ROI will help others in your organization and your team to build confidence in the automation implementation to understand potential benefits and gain. Gain will continue as the implementation evolves, as well as the investment to maintain test cases.

This concludes our series on QA automation. We can’t wait to bring you more information on how to think of quality differently with agility.

Feel free to comment and give your feedback below. Zsquare Solutions Inc specializes in supporting you and your team to define all the important pieces needed to craft your QA automation strategy. Schedule a 30 min consultation with us today so we can learn more about what you do and how we can support you in your goal.

Resources :

https://smartbear.com/resources/ebooks/6-ways-to-measure-the-roi-of-automated-testing/

Last month we began a three-part series called: What Is Your QA Automation Strategy? In the last article, we focused on determining the pain points, the organizational trade-off, and the technology stack to help determine your automation vision.

Now, let’s focus on what your vision ought to be. It will again depend on our team to define a clear vision, and where you want to see your organization after QA automation is implemented. You must set a QA automation Vision: your WHY? When you are embarking on a new journey, your WHY is your north star. It helps your team remain focused and motivated during the implementation.

It’s really important to create a clear vision of your automation goal.

Next, looking for tools becomes a crucial part of your automation strategy. With our tools, we need to consider the framework. I have seen many QA leaders and teams who want to jump in right after selecting a tool, but this is an approach that I really discourage.

In terms of tools, there are two main categories out there to consider for QA automation. There are the codeless tools where your team doesn’t have to know how to script particularly, they just need to follow some guidelines on how to screen capture and the tool will script in the background. In this case, the tester will have to understand the tool enough to continue to maintain all those test cases created. If this is what is going to work for your organization and your team, especially for manual testers, this will be easy to adapt.

The second category is the tool where you have to code everything yourself. That is an entire software development project you are taking on. As an organization or team, you need to determine if you have the skillset and the budget available to hire a full-time automation engineer. This staff member or automation engineer team will be fully focused on scripting the automation tests. Those are the considerations you have to take into account before selecting any tool. You also want to make sure that if the tool is proposing many features, your team and organization should be positioned in a way that you can easily benefit from a majority of those features. You want to embrace all those great benefits that the tool provides, but also, the team may need to come up with their own tool requirements before you begin shopping.

Most tools will integrate with your CI/CD pipeline, and have an ecosystem around them where you can integrate with your ALM easily. Some tools also provide Artificial intelligence to easily detect bugs or any changes, making the automation tool smarter and very helpful for triaging tests. Next, with a tool, you have to look into the capability of your team and ensure that the tool vendors are providing adequate support. Your team wants to make sure they can really have the support that they need when they’re doing the actual implementation.

Next time, we will conclude on these 3 parts series and discuss the ROI of QA automation and the implementation of the automation.

Feel free to comment and give your feedback below. Zsquare Solutions Inc specializes in supporting you and your team to define all the important pieces needed to craft your QA automation strategy. Schedule a 30 min consultation with us today so we can learn more about what you do and how we can support you in your goal.

During these unpreceded times of self-quarantine and social distancing, everyone is now encouraged to work remotely. Leaders must continue to lead their team remotely while keeping their team engaged, motivated and productive.

I want to share some of the best practices I have followed over the years since I have been working with distributed teams for the past 15 years.

Build relationships – Know your team member
An organization is a group of people working toward a common goal. Your organization has people; these people are human beings, guided by their emotions. These people have families and personal lives outside of their 9-5 working hours. As a leader, you ought to know your team members on a personal level. This is crucial to understand what is going on in their respective lives, and as much as they are willing to share. The best way to motivate people is to understand their circumstances, their personal motivation, and their communication style. This is something you ought to be doing as a leader anyway, but with a remote team it becomes even more crucial to help engage with your team better. The remote leader should demonstrate respect and consideration to your team members at all times during virtual communication.

Clear and honest communication
Increasing your communication with your team becomes very important with a remote team. Overly communicating is better than not communicating at all. Use all means of communication such as phone, text, email, video conference and chat communication. You need to understand their preferred communication style of each member of the team and adapt to each member’s preferred communication style. The leader should model and exemplify constant communication with the team with regard to their whereabouts all day. Having a shared calendar and updating it with all your meetings is a great way to make sure your team knows where you are at all times. Encourage your team to make their calendar open and available and keep it updated. Be very transparent and clear in your communication and share your expectations clearly. Remind the team of the deadlines and work expectations. If your team knows the value they are adding and what your expectations from them are, they will always step up to the challenge.

Structure your team meeting
This is a great opportunity to add some structure to your meetings. I suggest that you add structure instead of having unplanned last-minute meetings, as those don’t show leadership quality but instead micromanaging behaviors from the leader.

Below are my suggestions:
– Plan a biweekly meeting with your team, a quick check in for 20 min early in the week like Tuesday morning and later in the week for 40 min for a more in-depth meeting. I am an advocate for a short and concise meeting.

– Plan consistent one on one meetings with your team members weekly and have some office hours available so they can check in with you to increase collaboration. During the meeting, allow everyone to get involved. Some people can be distracted, so you as the leader need to keep them engaged.

– Get away from the boring meeting with deadly PowerPoint slides, make it fun, and provide everyone in the call the opportunity to get engaged and ensure you facilitate the conversation.

Increase collaboration
Leaders use the opportunity of being remote to increase collaboration with their team. You can use a whiteboard session for brainstorming activities and creative projects. You can provide office hours in your calendar so team members can check with you to answer questions to collaborate on their tasks, just like somebody will pop in your office to discuss or update you on an issue. As a leader, you can also use that opportunity to update team members that are less involved to check in with them. This is also an opportunity to create some shared learning activities where the team can come together to watch a webinar and discuss their learning and take aways. This will increase your team’s trust in your leadership. Most importantly, be sure to show an open-door policy.

Consistency in practicing an open-door policy
Your team needs to trust that when they need their leader, they will always be available. You have to keep consistency in everything you model as a leader. Your open-door policy becomes crucial when you are leading a remote team; since there is no face-to-face with your team, the members need to know that when they need you, you are available to answer their questions, concerns, clarify expectations and remove impediments.

Innovate your team dynamic
With a remote workforce, the leader needs to bring some innovation into their team dynamic. You have to get creative in everything you do, your communication style, your collaboration, and your meeting format. I suggest you start your meeting intentionally and sincerely wanting to know about what is going on with your team since everyone lives in different parts of the town, country, and world. What is new in your area, what have you heard that you can share, etc. It is also an opportunity to give time for everyone to speak and engage others in the conversation. Don’t always focus on work because this might be the only human interaction some team members might have the entire day. So, respect everyone’s opinion and opportunity to share what is on their minds. After all, we are all humans, and we have a need to be connected and share our feelings whether these feelings are work-related or not. Give that opportunity to your team and make it fun for them so they can continue to stay engaged and motivated.

In summary, most people that work remotely spend more than 8 hours working, so you need to make sure that they are cared for emotionally so they can focus on being productive instead of worrying about what their boss thinks of them when you micromanage or constantly check on them. Doing so does not show trust on your part to your team. In this difficult time, let’s be real leaders, and act like one by trusting our team members.

My hope is that we all will adopt the best practices to work with distributed teams that can continue even after this coronavirus pandemic is over. On this, I invite everyone to follow the experts’ recommendations (wash your hands, use hand sanitizer, practice social distancing, etc.) during this virus outbreak period. Stay safe, and stay productive.

I don’t know about you, but I used to be very anxious about QA automation when I was managing a QA Department. I know that automation was one of our goals and I used to be really anxious because it’s always something that we talk about and it seems to be a long-term plan. But we needed a concrete strategy. I was able to take my team through an amazing QA automation strategy, and then we executed that strategy successfully.

First of all, let’s start with who is responsible? That’s really important because I want to know who we are getting at the table when we are talking about the automation strategy. It’s everybody, it’s not just QA responsibility. It’s everybody’s responsibility; it has to be a collective goal.

The second thing we have to think about is: what are your current pain points? Nobody talks about automation when everything is going great. There’s always some kind of pain points that you’re trying to solve.

So, what are your pain points? (it’s different for every delivery team):

Lack of acceptance criteria in user story
Requirements are not well-defined
Defects are not prioritized
QA is the bottleneck
Lack of confidence in dev code quality
Too much time spent on testing activities

There are several pain points and they depend on your organization’s behavior and culture.

So you get to sit down around the table with your team and define and discuss the pain points that you have. And why are we trying to automate? At least that is your starting point.

The other things that a lot of people miss are – what is your trade-off in every organization or team? It’s not just about the delivery teams, you have other people or circumstances that are influencing the decision, and there is always a reason why you are trying to automate;

One of the reasons might be that you are in the department, or organization where you innovate a lot, so you feel like automation might be the answer. You are rapidly innovating so you need to quickly automate your test case, and can quickly test. Innovation and fast delivery are probably one of the reasons why you think about automation.

Cost-saving is another driver. I hear often, QA taking too long for testing, and we know time is money. You can also be trying to deliver value for your customer, for instance, if your customer or client is the one that also needs it fast then you need to show them something really quick. Therefore, we need to automate tests really quickly and be able to show the customer. We need to know and understand all the tradeoffs.

The third part that I want to tackle, which is really important, is the technology stack that you have. Each organization is different, it might be one huge application that you’re trying to automate, or it might just be you have several or at least in one of the engagements that I have worked with previously. We had to find the one tool that could solve all applications.

So this might not be your case. I might just be one application you’re looking for as one tool, or you may have multiple applications you’re looking for with one two or several tools. You have to determine what technologies stack you have.

The following information is crucial: what language will you use? Is it on-premises? Is it in the cloud? Where your code repository, where your test repository, where is your environment? What kind of environment you have?

Then, you need to look at all the trends that are out there and decide together as a team.

These are the main three things that I would like you to take away from this first article when considering a QA automation strategy.

Finally, these are the following questions you should ask when you begin a QA automation strategy:

First of all, who is responsible?

What is your goal?

What are your pain points?

What are your drivers? What are the trade-offs?

What is the technology stack?

When you can seriously answer these questions with your team, then you can begin to look at the current trends and try to solve each of the pain points. In my next article, I am going to discuss how to put your defined vision into automation, the framework choice and how you can successfully execute your strategy.

Feel free to comment and give your feedback below. Zsquare Solutions Inc specializes in supporting you and your team to define all the important pieces needed to craft your QA automation strategy. Schedule a 30 min consultation with us today so we can learn more about what you do and how we can support you in your goal.

In today’s article, I want to tackle how e-commerce sites can get ready for the holiday season.

Obviously, I have been in software development testing for 15 years, but my other title is a self-acclaimed shopaholic! I love shopping and I’ve been on numerous e-commerce sites and the challenge that I always see is that they make it very hard to get my money. I don’t have a lot of patience.

I want to share some tips on how to prepare, so your QA team or your technical team can lookout to have your e-commerce site ready for the holiday shopping season.

First, you want to make sure that your site is performing fast, meaning the response time is quick. The website needs to be mobile friendly because all of us these days are on our phones and when we receive a link and we want to go check it out right away from our phone. We want to start the shopping process right there and then from our phone. So, your website should be easy to access and respond fast.

You have to ensure that you have a quality image that you load on your website, usually, those quality images have higher resolution and it can take a lot more time to load. Your team needs to make sure that the website can load really fast. The users do not want to spend too much time loading the images to come through. Make sure that your site is easily scrollable too. Users want to quickly easily scroll and see an image fast.

Secondly, you have to make your website very user-friendly and make the experience easy for your users. Users should be able to easily and quickly find any item.

Users should be able to have a search bar on the top easily reachable where they can quickly type keywords that can easily give them more suggestions on the item that is possibly available to find.

Once the item is found, the user should be able to have a quick simple description to be able to add it to the shopping cart. The last piece is the checkout process.

The checkout process is where most companies actually lose customers. That’s where the customers get lost because your checkout processing needs to be seamless. Basically, while the user is adding items to the cart, the user should be able to see an icon in the top corner telling them how many items have been added.

Also, the total amount of the item(s) in the cart should be made seen for customers under budget constraint so these customers need to know if they need to make some trade-off right away before the checkout.

Users should also be able to easily remove item, edit and or add an item during the checkout process so that if you have any checkout coupon, you can use them. I don’t recommend them. If you have to make a coupon for checkout, make the coupon very easy to find on top as a banner where shoppers can easily copy and paste it into the coupon bar in the coupon area and quickly get a coupon. Please don’t make your coupon code something that is very difficult to type in, nor make the coupon code difficult to figure out.

The key to the checkout process is to make it secure and fast; the most crucial part of the checkout process has to do with the payment processing portion.

You want to make sure that you use already known payment providers such as Apple Pay, Samsung Pay, Amazon Pay and if possible use Paypal because you want to make sure that you use a system that already has your users’ critical information like addresses.

The reason for using known payment providers mentioned above is that most shoppers do not want to have to get their card in the middle of the night and fill out the information.

Furthermore, users would be able to quickly get the confirmation right after they make the payment.

Overall your e-commerce site needs to be ready so that you can be able to get in the 1.1 trillion-dollar amount that will be spent this holiday season. You want to make it easier to get the money from millions of users that will be on your e-commerce site.

Therefore, the performance of your site is important.

It’s not just about your functional testing, but the performance of your website does also matter because the last thing you want is your website to crash when people come on your website. You have to make sure that the concurrent number of the users that can be on your website is known and you have a capability in your server and application to be able to hold that number of concurrent users.

You’re going to make sure that your checkout process is a very easy and user-friendly website where people can find items very fast.

If you have any e-commerce site that you are actively working on, please check out our services on our website and request a 30 min consultation. I should be able to review your site and give you some tips, directions, and strategies into how you can win this holiday season and make the most out of the e-commerce site.

If you have any comments or feedback or questions, leave them below and I will be happy to respond.

Thank you and enjoy your holiday shopping!

Agile First-Class Citizen

By Lisette Zounon, CSM- CSP, DTM

Today I wanted to share a little bit about a talk that I had last week.

I had the opportunity to give a lightning talk at the DFW Scrum user group. My talk was titled “Agile First-Class Citizen.”

Usually, if you have ever been in any agile training, what we learn about agile and scrum role include the following:

1- Product Owner

2- Scrum Master

3- The Last Development Team Everybody else is a group under the development team.

I’ve seen organizations use that as an excuse to exclude the Quality Assurance Analyst, Quality Engineer, or tester from the team. The organization is usually saying we’re going to do an agile transformation. We are going to start a DevOps transformation, so we don’t need a QA. When I hear that, it is usually the following complaint that starts experimenting with a lot of quality challenges. One of my clients just told me that sometimes they don’t even know what went into production, they don’t even know what kind of application they have, who and what was tested? The user group is usually complaining because they are having a lot of issues in production.

Who should be responsible for testing? I strongly believe QA should be responsible for testing. It should be somebody solely responsible for testing, somebody that is solely independent and also advocating for the stakeholders and the users, that knows how users are going to use the application. QA should come up with scenarios/test cases to test user experience and expectations of the application, software or product. So, we need to make sure it’s somebody that is independent.

Three things make QA a valuable asset in software delivery:

1- First, we have the best view of software delivery. We are the one that know if the application is going to work, how it is going to work, and looking at a possible issue.

2- Second, we deliver value, we define and determine the quality of the software, such as how many bugs coming through, and the severity of the bug.

We understand how the software is going to work first hand because one thing is to say have a requirement defined, but by the time you get to QA, you know for sure that the software is going to be working and it’s going to meet the requirements that you expect. You also know in the delivery how long everything will take, because we spend a lot of time estimating during sprint planning. By the time you get to QA, you know if the developer tells you it’s going to take you 5 hours for a user story, and it took him twenty-five hours.

3- Last, we are also change agents. I have been fortunate to be involved in two agile transformations. They are not always successful, but they are a transformation because the organization is trying to move from a waterfall or whatever methodology to an agile framework. In both transformations, I didn’t come in as a coach or a consultant. First, I was a QA lead. I was a QA team member in the scrum team, and I was able to influence my team into adopting some agile best practices based on issues that we were seeing and that we needed to improve upon. We were able to adapt as we went for what was needed for our team.

For the second time, I came in as a QA manager, leading a large QA team. Our inside joke was that my team members were QA FBI agents that would go into the different projects and impact the change that was needed based on issues the team was facing in their software delivery. Therefore, they were acting as a change agent. As a QA professional, you have to be a leader without a title because you don’t have the authority as a consultant that is higher up to impact and demand change. But, you have the first-hand and the first view, the best view of what is happening, and you can affect change right there and then if you can find your voice.

The takeaway and call to action that I gave the group in my talk with a room filled with agile practitioners, agile coaches, scrum masters, and agile consultants was to reconsider their approach to agile transformation. Don’t just come and interact with developers or scrum masters, get close to your QA professionals on the scrum teams. Make them the central part of the decision and discussion about the challenges you are here to solve. Listen to them. What are the opportunities to grow for the team? What are the areas of improvements in the software delivery? Because your QA professional has the best view, we are the first-class citizen in agile transformation.

My approach to agile transformation is to focus on solving quality challenges changing the way of working for the team. As the team grows, so does their performance, and in return solving all the quality challenges, and delighting your customers and users at the end. It is like beginning with the end in mind, my favorite of the famous seven habits. That is how we approach agile transformation at ZSI- Zsquare Solutions Inc. We are QA professionals and agile coachs, consultants with a passion for quality, purposely changing the way of working to make your team and customer happy. Book a 30 min consultation with us here to discuss your current projects and your 2020 QA initiatives to start solving your pain points right away. Everyone has pain points and your project and your team cannot wait.

I love to hear your thoughts or horror stories. Comment below about your experience with QA or QA in the software delivery in an agile or scrum team. If you have any questions or if there’s any topic that you want me to share next month, please comment below and I will be more than happy to cover them.