The multiplication of innovations and the immense accessibility of data have changed the way administrations and products are made and delivered. These progressions are making it conceivable to deal with the nature of items such as the client’s untimed requirements/changes, bugs, quality checks, etc. at each phase of the interaction rather than resolving them all together at the end of the production cycle. This indirectly satisfies the ultimate goal of customer service i.e., timely delivery, incorporation of all the requirements, and avoidance of unnecessary costs. As a standard protocol in the manufacturing and software development space specifically, companies are now moving away from Quality Assurance (QA) and towards Quality Engineering (QE).

The beginning of Quality Assurance itself was embraced by the businesses which essentially worked using a waterfall model, whereby any phase in the development process begins only if the previous phase is complete. Consequently, it shocked no one that software companies themselves followed a comparable model for manufacturing software. Software Quality Assurance followed a similar pattern and was occupied with assuring quality instead of engineering it. For a while, this seemed to work fine, but this changed with the advent of iterative development— better known in our business as Agile Development. Agile development flipped the model on its head in terms of software development timelines and delivery. It required teams to adjust to a cycle that supported smaller development and more frequent deliveries instead of longer development periods and fewer deliveries all at once. This greatly affected how testing was conducted. In this model, QA was required to test the entire framework every two weeks dependent on the run cycle. While this was feasible when the item was more predictable, as advancement progressed, it became progressively harder for the QA teams to keep up. The requirement for quicker, utilitarian testing and signoff brought:  

• Renewed stress on moving quality upstream
• Mechanization and computerized testing arrangements
• The introduction of CI/CD (Continuous Integration/Delivery) pipeline, and
• A greater role to play for the quality assurance team.

This transition catalyzed a redefinition of the QA role which caused a ripple effect, ultimately leading to a redefinition of the QE role.

About Jon

Jon is the Founder and CEO of Snow Media Ltd based in Winterfell. His Wife, Ms. Ygritte is one of the board members along with several other board members, namely Robb Stark, Arya Stark, Sansa Stark, and Bran Stark. Snow Media Ltd. has several businesses including Snow Production House, Snow VFX services, OTT named Dragon Glass Video, and Westeros Technologies.

Jon’s Plan

In the recent past, Jon has come across news about user information being leaked by social media companies like Facebook, Twitter, etc. Turns out, these mammoth companies were minting money by selling this information. This is when Jon and the board arranged several meetings to develop a solution to this issue that would be available to the public. After several discussions with the board, Robb and Arya developed a plan where they would build an application that would have two options: 1) the user can stop the cookies from tracking the user’s movement and 2) the app would let the cookies track the user movements but in exchange, users would be rewarded by the companies who need these details. Snow Media would take a certain percentage of the share before dispensing the monetary reward to the user. On December 16, 2019, Robb arranges a meeting with Ms. Daenerys Targaryen aka Dany (Head of Westeros), and instructs Dany to build a dedicated team for the execution. 

The Agile Team & Agile Development – Battle in Winterfell

The Team was led by Ms. Cersei Lannister, the Project Manager. She would be responsible for the planning, organizing, directing, and finishing of a complete project. She and the team members discussed the minute details like design, technicalities, priorities, timelines, etc. They also decided to have a sprint meeting every other Friday to discuss the progress, challenges, changes, and feedback.

Business analysts gathered all the information and requirements and documented them. Cersei, with the help of other team members, built the roadmap as per the priorities set so that in every sprint meeting, they would aim to have a potentially deployable product. Team members’ agility and flexibility were what was most required by Cersei to execute this project effectively on the estimated timeline.

The battle (project) took off. All the team members dealt with a rigorous schedule to enhance the product. Designers started designing high and low-level designs. Then programmers coded to make the design functional, followed by quality analysts who constantly developed tests, tested each individual, and merged functionality. The squad was constantly delivering a working product in every sprint, incrementally bringing it to life, and were able to match the set timeline.

The Bomb Dropped

Fast forward four months, Robb met his friend and mentor, Eddard, over dinner. They talked about family, work, future plans, past projects, and more. Eddard revealed one of his past projects that had a lot of project delays which ultimately delayed his launch date. Rising competition, opportunity cost, and loss of potential clients followed. This all took place because of an unenlightened reason. Eddard briefed that he and his team were very particular about the quality of the product. The product was clearing all the quality tests with impressive numbers, but after the launch of the beta version, customers had difficulty using the product. The company constantly received disappointing feedback like ‘product was too technical’, ‘too clumsy’, ‘confusing’, ‘boring’, and other criticisms. They figured out that the product was not user-friendly, but was unable to ascertain feasible amendments. After few more conversation exchanges, Eddard saw the sulking face of Robb. Robb was absorbing and contemplating Eddard’s story. To break the silence, Eddard laughed, cheered him up, and talked about the lesson he had learned the hard way from this project. 

The Rescue Motivation

Robb Urgently called a team meeting to discuss this issue and a solution. He narrated the issue story of Eddard, his product, and how he suffered delays and losses. Tactfully, he tried to motivate his team. He said “Who are we working for? For whom are we trying to innovate and build new products? Our customers, right?” Everyone nodded. He continued “Great! Now tell me something. There are 7 billion people in this world, would all of them be as technically sound as we are? No, right? In fact, most of them are not proficient in understanding the technology offered to them. They see the usability, user experience, aesthetics, speed, and convenience of the product. That’s what they understand and what matters to them in a final product. – and our goal is to build a final product that meets these expectations and eliminate any technical matters that become a hassle. They have to use this product day in and day out, and our goal is to eliminate hassle and friction to make it enjoyable and likely that they would recommend the product. If we don’t, this translates to low production adoption, loss of revenue, wastage of time, wastage of energy, etc. I know the quality team is working hard to find bugs and the development team is working hard to remove them, which is necessary, but this is not our whole purpose of building a new product. Let’s work together, develop a customer-focused mindset, and empathize with the layman customer. Developers: develop the product keeping in mind a layman’s usability and experience, and the same thing with the quality team. Quality team: develop tests keeping our layman customer in mind rather than focusing on finding bugs.”

The team agreed and nodded. “I’d like for you all to act and perform as an individual spokesperson of customer-focused culture in this organization. From now on, we will move from a QUALITY ASSURANCE to a QUALITY ENGINEERING mindset, where everyone will work together for the final consumer, develop and test product like it’s the requirement of a customer. We will develop the highest quality product by keeping it simple, functional, and convenient yet amazing. Just think about the customer and how would they use it and we will have a paved path ahead of us.”

Impact of Software Quality Assurance (SQE) and how is it Different from Software Quality Assurance) SQA?

• SQE Motivates the developer to think about customer perspective and their usability, whereas SQA only checks the functionality and quality of the final product.
• SQE is centered around having the right testing instruments for every advancement stage, while SQA takes a “one-size-fits-all” approach.
• SQE tries to keep things agile and adaptable, while SQA looks at the master plan
• SQE takes a customer-centric approach where each team member gives utmost importance to customer satisfaction by developing per their convenience. SQA merely focused on satisfying the customer by removing defects from the product.
• SQE Develops a quality framework that requires items to be iteratively met at various stages, naturally creating the best item, whereas SQA tries to keep up the product straightforwardly as planned since day one.

Design Thinking – The Way to Achieve SQE

In the book ‘The Timeless way of Building’ the author Christopher Alexander states “Pattern all the way down”. He discusses pattern language, stating there are 253 patterns that serve as generic guiding principles for design. Everything in this world follows a pattern, from the growth of a leaf on a tree to the stock market to human behavior. Similarly, software development follows patterns and processes to achieve results, and when it comes to considering the customer, a pattern/process called DESIGN THINKING is applied. Design Thinking was developed because of the lack of innovation and creativity in large corporations during extreme competition. When companies were unable to develop products or services that would actually meet the unmet desires of a layperson, Design Thinking was introduced as a prevention to avoid such doomed situations.

Design Thinking consists of five steps. These steps are used on a regular basis to inculcate the culture of SQE at Aureus Tech Systems, a Microsoft Gold Certified Co-Sell Partner and product and solution digital transformation company. Each of the five steps is explained below using examples.

Empathize- Westeros Technologies took on programming and DevOps engineering project with a gaming company (Rockstar Games). Cersei was assigned to lead the quality. In the initial client meeting, to be able to empathize with the customer, Cersei asked clarifying questions to ensure she understood the programming requirement and fully internalized what the customer desires and expects. As she was asking these questions, the memory of playing PlayStation video games with her son Joffrey popped into her head. Joffrey perceiving the game through his experience her thinks of the company’s niche customer segment before directly jumping into the project. Her son’s point of view, experiences, and expectations from the game would be very genuine and unbiased. Now she has an understanding of the end-user, The whole crux of the story is to empathize with the customer and dig deep to understand what the customer is actually facing and what is he/she is expecting. Cersei attended the meeting with a brief knowledge of what an end-user would expect from the game.

Define- Once Empathizing finishes, Cersei would have all the necessary details and information. This is where Cersei would analyze her observations and arrange them in order to understand and define the core problem that has been identified by herself and the team at this very moment. Cersei has to define the problem statement in a human-centered manner. For example, after evaluating all her observations, she found out that end customers had to switch to an ethernet connection to save the game from lagging. The game lags endlessly on a Wi-Fi connection. This problem statement has to be defined in a crisp & concrete but human-centered way. For example- ‘75% of the gamers face lags while playing the game on a Wi-Fi connection, we need to remove bugs and enhance quality to elevate customer experience’. The Define stage will help the designers/developers in the group accumulate extraordinary thoughts to build up highlights, capacities, and whatever other components that will permit them to tackle the issues or, at any rate, allow users to resolve issues themselves with the minimum difficulty.

Ideate- While being in the defining state, the team would start getting ready for the next step i.e., Ideating. This means once the team is totally clear with the problem statement, everyone would now start coming up with the potential solution to the issue. Designers and developers in Cersei’s team will hold ideation sessions in order to come up with as many new angles and ideas as possible. This is the stage of creativity without judgment. Several ideations that team members use to develop solutions are brainstorming, role-playing, provocation, mind mapping, etc. By the end, out of all the solutions, Cersei’s team would narrow down those solutions which are most likely to be useful for the end-user/layman.

Prototype- Next step is the prototype. This step basically focuses on bringing the probable solutions into life. Solution on paper will not resolve customer issues. The Prototype is basically a pilot/scaled-down version of the actual probable product. Now, as it has been already mentioned, prototype development has to be done keeping a regular gamer, his use, his experience in mind. Because we are in an experimental phase, this prototype model can be tested by self-team or by people outside the development team. As discussed in the ideate phase about narrowing down the probable solution, the prototype will be developed for all those probable solutions.

Testing- Out of all these prototypes, either would be accepted or rejected or would be sent to improve and re-examine on the basis of user experience. The last phase is the testing phase where quality testers would develop tests as per the end user’s use of the product. The test would check for the experience, convenience, and usability of the final product. This test would take place in every sprint. Without the clearance, it would not go for release/next sprint. There are a lot of probable chances that most of the time, in the step of testing, the prototype would go back to an old step to improve and retest again. This generally halts the process but if we have a bird view, this actually saves time by reducing the probability of failing at the final testing.

All in all, the most important part of designing thinking is Empathy. Emphasize with the customer, try to know him, his problem, cause of the problems, effects of the problems, ask questions & try to interact as much as possible. Being customer-focused, being customer-centric is the whole idea of using Design thinking to transform from SQA to SQE.

Why Do We Need SQA to SQE transformation at AUREUS?

There is a quote said by the Dutch Philosopher Desiderius Erasmus which says ‘Prevention is Better than Cure’. 

Customer satisfaction is one of the key principles of SQA and people confuse the same with resolving defects. Resolving defects indirectly resembles serving Cure. At Aureus, we want everyone to focus on prevention and what could be better prevention than showing empathy to our customers. The Change of SQA to SQE is basically a change in the mindset of our people. The mindset where they would focus on the customer, their needs, their experience, and their usability. The mindset does not just focus on defects but also a greater focus on working together towards a common goal i.e., getting the hold of a layman’s thought process and striving to achieve his expectation and that Mindset which does not just focus on developing technical skills but also work towards developing Business acumen. Let’s all try together to build this culture and make Aureus a better place.