Quality Management

How to use quality gates to guide IT projects?

admin — Tue, 19 Dec 2023 17:51:00 +0000

How to use quality gates to guide IT projects? admin Wed, 12/20/2023 - 00:51

John Sinclair sits in an IT operations room where he’s responsible for managing a team fielding user calls about server and application support issues. The ops room, which looks vaguely like a NASA control room, is full of digital displays monitoring critical processes and servers on a 24/7/365 basis. John’s team is highly trained on the key enterprise software applications and services being run throughout the entire IT organization. The team monitors Veritas backup scheduling, midrange UX, NT server, mainframe, and security. His capable team rapidly responds to calls from users worldwide. “It’s really a question of knowing what’s out there and that we can fully support it,” John said.

Unfortunately, the team doesn’t always know what’s out there. John recalled a Monday morning when all hell broke loose. The help desk call volume suddenly increased by 30 percent. Users complained that they could not access data or asked questions such as, “Did you guys maybe run backups on dev server JEDIDEV01l last Friday?”

John said this situation happens all the time. In this case, his team didn’t know anything about the project—not even the names of the contact people for that server or all the assets that were included for that project. Also, it was assumed his team would automatically manage the development environment for that specific project team. “No one bothered to tell us,” he said. “If we had used the quality gates technique, we would have been prepared, and all that heartache could’ve been avoided.”

Marc Dutton, an executive in portfolio management for a large pharmaceutical client, became similarly frustrated at how many project managers simply fail to transition projects properly between these project phases:

Design to development
Development to deployment
Deployment to operations

At the end of the day, project management isn’t always about delivering a project as quickly as you can. Often, it’s about ensuring that the project has been well thought out technically and can be supported after it is deployed.

Understanding quality gates

Quality gates are basically acceptance criteria reviews that can be used throughout any project. Sure, managers of smaller, agile projects might say that this involves too much paperwork, but the nice thing about quality gates is that the strategy is fully customizable. It can be seen as a set of predefined quality criteria that a software development project must meet in order to proceed from one stage of its lifecycle to the next. (Figure A shows a typical schema of quality gates.)

Let’s illustrate this process using the following example: You’re appointed as project manager for a large CRM project during the development phase. Your design team e-mails the MS Visio diagrams of the architecture to the development team. The developers proceed to configure and customize the CRM application as per the design team spec. Later, you determine from the infrastructure team that the dev environment and infrastructure aren’t yet in place (e.g., there’s no database support, and IP addresses and DASD still need to be assigned). This oversight impacts the timeline. If you had utilized the quality gates process, you would have detected at the “design phase” gate that the project plan didn’t:

Detail the development environment
Address networking
Determine external storage or disc to be assigned

You can avoid such problems if you’re familiar with the technology and do it on a day-to-day basis. But, in reality, many project managers move from one type of project to the next, and it is likely they will forget something. So, project managers tend to build elaborate project schedules that encompass everything and ignore the key gate reviews or checklists that make or break a project.

Here’s how quality gates work: You cannot proceed to the next gate until the previous gate has been completed. This will typically involve a checklist of deliverables, with some indication of the state of completion for each item. This checklist must be reviewed by the IT project manager and a senior executive or sponsor who is involved with the project. Quality gates therefore mean:

Formal checklists are used throughout the life of a project.
Formal sign-off and acceptance occurs at each gate.
Assessment of the quality and integrity of the product takes place.
Information is assured to be communicated to the correct stakeholders (i.e., deployment hands off to operations, etc.).

Quality gates can be highly effective on any project. There are distinct advantages that make quality gates so attractive. Those advantages include:

Minimizing project risk through phase-by-phase checklists
Enabling project managers to continuously communicate the process and build quality directly into the project
Reducing development cycle time—getting it done right the first time
Increasing focus on a well-designed product

Unlocking the gates

So, where do we begin implementing quality gates on a project? The most important thing to understand is that the quality gates concept is best suited for enterprises that have the desire to instill a quality approach to the way they manage projects. Sure, this article doesn’t address every single aspect and technique of quality management, but it ensures that you address many problems upstream instead of downstream. Companies such as AT&T, Lucent Technologies, and many others have successfully implemented quality gates. It’s a process that needs to be driven from the top down for all IT projects. This isn’t something done overnight, either. The reason is that quality gates need to be integrated with both the development and deployment processes of your IT project. If you would like to implement this concept from scratch within your organization and currently have multiple projects already under way, the best recommendation is to complete those projects and establish a policy that all new projects coming in after a certain date will use quality gates.

For each phase of the project—depending upon your organization—you need to develop a series of checklists, which is used during a formal review period (for example, the review format could be an hour meeting or a workshop). These reviews prompt the project team to evaluate technical progress, specs, and project milestones. These formal quality gate reviews can also be applied to measure project cost and schedule performance, and to provide checkpoints to enable the baselining of key project information. The quality gate reviews play a significant part of any project development cycle.

For example, if you are managing a software project and the development phase has just been completed, the quality gate concept will kick in by means of a formal meeting, which is held with individual members of the project. At this stage, the examination of the project would typically encompass the following:

Code review: The senior designer (normally the tech leader) will concentrate on acceptable coding techniques and adherence to IT standards. The software design will be verified against the coding to identify any coding errors. Upon successful completion of the code review, the reviewing party will indicate required changes and corrections.
Ops review: The project manager will work with the support or operational staff to review all support tasks needed to support the dev environment. For instance, the ops review will ensure that the necessary backup and restore procedures are in place, discs are available, escalation procedures have been created, etc.
Sponsor review: The project manager will review the overall project performance with the sponsor. This review will determine the status of project costs and schedule and whether the scope is still accurate.
Test review: The test lead and representatives from QA will attend the test review to see if all builds were tested correctly and make sure that all relevant questions have been posed to the development team.

Once these meetings have been held and all the questions answered and accounted for, the quality gate review team reports to the stakeholders that the project has signed off on all relevant items for that particular phase and that the project may proceed to the next phase. (For example, without gate reviews, one of the biggest areas we tend to neglect is turning over the system for support.) Figure B highlights sample checklist questions that need review once a system is handed off to production.

Ignore quality gates at your peril. It’s an important process for your project when transitioning from one environment to the next. Don’t torpedo your IT project by thinking that this is yet another series of useless documents to be completed. More and more IT organizations are now starting to compile and use such checklists on their projects.

Category

IT Consulting

Benchmarking and Software Benchmarks

admin — Tue, 12 Dec 2023 16:40:35 +0000

Benchmarking and Software Benchmarks admin Tue, 12/12/2023 - 23:40

Donald J. Reifer is recognized as one of the leading figures in the fields of software engineering and management with more 40+ years of progressive management experience in both industry and government.

Software development processes have evolved over the past decades as people learn what works and what doesn't work. Although we don't have centuries of experience like other fields such as building houses, we have learned a great deal. There has been some pushback against the long formal software development processes (waterfall) that have been replaced with Agile software development. But some formal processes are still needed to match the agility. Included in these processes is the important concept of software benchmarking.

What is software benchmarking?

Software benchmarking is the collection of and comparison of data from multiple sources. This process doesn't necessarily have to do with software, and recognizing that helps you build a formal plan for software benchmarking. On the other hand, you might be benchmarking the software development process itself to determine if teams are working as efficiently as possible.

Consider the situation of comparing insurance rates. You might make a few phone calls, visit a few websites, and gather up the data but before you can compare the data, you need to normalize it to make sure you're not comparing apples to oranges. Are you comparing monthly rates to bi-annual rates? Are the rates for the same services? Similarly, with benchmarking software development processes, you have to make sure your data is normalized. To get the data normalized, you need to use a formal process, just as you do with software quality in general. In a sense, designing a software benchmark is similar to architecting software itself.

Software benchmarking process

Needs assessment: What are you trying to accomplish? Create the questions you need answered, and determine if those questions cover everything, you need to know. Are you factoring in cost? Often software developers think of software benchmarking strictly in terms of time, i.e. which program runs faster. But benchmarking is much broader and includes costs, quality, and so on.
Industry/Domain Classification: You need to determine what type of benchmarking you need based on the industry and domain. From there you can determine whether you can use standard benchmarking tests developed by experts, or if you need to develop your own, specific benchmarking tests.
Data Collection: This step is, of course, vital, yet it's easy to take it too lightly. In the previous steps, you determined what data you need, in this step, we cover not just the data collection itself, but how you're going to collect it. Some data might be collected automatically by software; other data might be collected through surveys from users. The data collection process might take only minutes; or, it might take months, depending on your needs. In either case, you'll want to survey the data you're collecting to make sure it's consistent and is providing the information you need.
Data Normalization and Purification: As the data comes in, you need to make sure it's normalized. A trivial example is that if some data is in US dollars and other data is in Euros, you need to normalize it to a single currency. You also need to remove data that might be inaccurate or could improperly skew the results. This, of course, will likely involve standard statistical models and methods.
Data Comparison and Benchmark Preparation: After the data is collected, you have your benchmarks. More analysis takes place here, however. If the data seems incorrect, then perhaps it is. Do some more digging and find out why, and if the tests need to be performed again.
Benchmark Reporting: The process of reporting the data is also not trivial. The results need to be presented in an accurate but usable fashion target at a specific audience. Business managers would need different information than technical managers.
Improvement Recommendations: As with any process, your benchmarking process will likely have room for improvement. Are you gathering the necessary data? Are you packaging the results into reports that are useful?

Via:

Category

IT Consulting

Ishikawa (fishbone) diagram in software project management

admin — Thu, 08 Dec 2022 04:47:13 +0000

Ishikawa (fishbone) diagram in software project management admin Thu, 12/08/2022 - 11:47

The Ishikawa diagram, also known as a fishbone diagram, is a useful tool in project management, particularly when it comes to quality control.

This diagram was created by Professor Kaoru Ishikawa to make brainstorming sessions more effective at conducting a thorough root cause analysis.

Conducting a proper risk analysis, anticipating and solving problems are essential management skills to lead successful projects. These aspects should be taken into account as soon as the project planning phase begins. Luckily, presenting the root causes of a challenge and the ways to overcome it is the very purpose of a fishbone diagram.

Learn more about the Ishikawa diagram, how it’s used in project management and how to build your own!

An overview of the Ishikawa diagram

What are fishbone diagrams used for?

This diagram was created by Professor Kaoru Ishikawa to make brainstorming sessions more effective at conducting a thorough root cause analysis. After the project team has discussed a problem, it is used to sort all the ideas into categories.

Using this visualization allows your team to:

Take a step back and think about a phenomenon or challenge,
Communicate and share ideas more effectively,
Make decisions more quickly.

Kaoru Ishikawa 11 Points

Mr. Ishikawa's philosophy of total quality management can be summarized by his 11 points:

Quality begins and ends with education.
The first step in quality is to know the requirements of the customer.
The ideal state of quality control is when quality inspection is no longer necessary.
Remove the root cause, not symptoms.
Quality control is the responsibility of all workers and all divisions.
Do not confuse means with objectives.
Put quality first and set your sights on long-term objectives.
Marketing is the entrance and exit of quality.
Top management must not show anger when facts are presented to subordinates.
Ninety-five percent of the problem in a company can be solved by the seven tools of quality.
Data without dispersion information are false data.

Ishikawa example:

How does a Ishikawa diagram work?

What makes this tool a favorite of project managers and quality professionals is its ease of use. It is simply read from left to right and can be used to collaborate with others on problem-solving.

This visual representation resembles fishbones and helps analyze the causes and consequences of a given problem. Therefore, some may call it a cause and effect diagram:

The fishbones are oriented on the left-hand side and represent the causes,
The head of the fish represents the final effect of the problem.

Ishikawa diagram to analyze requirement failures

When should the Ishikawa diagram be used?

An Ishikawa diagram is a diagram that shows the causes of an event and is often used in manufacturing and product development to outline the different steps in a process, demonstrate where quality control issues might arise, and determine which resources are required at specific times.

Easier Root Cause Analysis for Remote Teams

One of the main challenges remote teams face when conducting root cause analysis is coordinating and communicating effectively. It can be difficult, primarily if team members are spread across different time zones.

Another challenge is ensuring that tasks or follow-ups are assigned to the correct person or team. In a remote setup, it’s easy to forget who’s responsible for what and to track tasks that aren’t assigned right away. However, there are tools like SafetyCulture that can help with this issue.

Via TIGO

Category

Methodology

Is gold plating good or bad in project management?

admin — Wed, 19 Oct 2022 15:18:38 +0000

Is gold plating good or bad in project management? admin Wed, 10/19/2022 - 22:18

For example: after having met the requirements, the project manager or the developer works on further enhancing the product, thinking the customer will be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.

'Gold plating' means the addition of any feature not considered in the original scope plan (PMBOK) or product description (PRINCE2) at any point of the project. This is because it introduces a new source of risks to the original planning such as additional testing, documentation, costs, or timelines. However, avoiding gold plating does not prevent new features from being added to the project; they can be added at any time as long as they follow the official change procedure and the impact of the change in all the areas of the project is taken into consideration.

Effects of Gold Plating

Even the best outcomes of gold plating can ultimately lead to negative realities for a project manager or for the project as a whole. In a best-case scenario, the customer accepts the project deliverable with the out-of-scope work, and customer expectations on future projects may forever be elevated to unrealistic levels. In a worst-case scenario, the customer might reject the project deliverable entirely and nullify the contract.

What’s the difference between Gold Plating and Scope Creep?

The simple difference between the two comes from who requested it. If the client requested additional functionality but it was not paid for, it comes under “scope creep”, whilst if the person takes it upon themselves to add in additional functionality without checking first, this would be gold plating?

Why is gold plating a problem?

If the client or end user is getting a better product, why should gold plating matter? The main factor behind this is that the client didn’t ask for these improvements or they may perhaps not even want them/not want to move in that direction.

How to avoid gold plating in your projects?

At TIGO, our PMO office would always recommend ensuring that everyone understands the tasks that they are due to deliver, what needs to happen, what is needing to be delivered and then understands the boundaries of the tasks that they are performing. Project Managers explain all of this during the backlog /planning meetings so that everyone knows what is expected. During on-the-job training, our junior PM is guided through showing the consequences of gold plating (which can be rework/ hours not being approved) and am very strict on not only scope control but also monitoring the deliverables against the scope definition.

Conclusion

Gold plating is considered a bad project management practice for different project management best practices and methodologies such as Project Management Body of Knowledge (PMBOK) and PRINCE2.

Being a Project Manager is not always easy, and yes, you may be seen as the strict holder of the scope definition bit both gold plating and scope creep are not good for you, your project or your organization.

Via TIGO Solutions

Category

PMP - Project Management Best Practices

What is a Software Post-Mortem?

admin — Wed, 21 Sep 2022 14:36:31 +0000

What is a Software Post-Mortem? admin Wed, 09/21/2022 - 21:36

There are software bugs that can end up crippling companies if they aren't dealt with rapidly.

The Knight Capitol Group was an American financial services company. A technician forgot to copy some new code to a computer server, and this software release caused to them to lose $440 million. This happened because one of the computer servers started to rapidly purchase stock (it completed over 4 million purchases and sales) over a 45 minute period.

Not every software bug is as dramatic. But there are moments as a software developer where you have to resolve bugs as fast as you can.

I recently learned about companies releasing publicly accessible post-mortems on their emergency bugs, and dove head first into them.

What is a post-mortem?

A post-mortem is where a team reflects on what went wrong with something they did, and documents it and/or amends their process to stop it happening again.

Did a software release go bad? Let's break down a timeline of where things started to go wrong, and let's reflect how we could have caught it earlier.

Here is the most important point: Post-mortems ARE NOT to assign blame. If we look at The Knight Capitol Group example, there should have been no way for one person to forget something and cripple the company.

Where was the quality assurance process where someone checked the technician's work? Did they test this before going to production? Were there no automatic tests that ran before the deploy to production succeeded?

You should be finding process failures not personal failures.

Why should we do a post-mortem?

So we can stop making the same mistake over and over!

We provide more robust, bug free, stable software by learning how we failed in the past.

Most importantly, we can catch bugs we don't even know about. And if we fix the processes that were prone to cause issues early, then those mistakes won't even happen.

We want to learn every single lesson we can from the outages and emergencies to ensure they never happen again. Nothing is more valuable than experience.

Let's look at some post-mortems together

I wanted a little bit of variety of companies and languages, so let's review some from Google, Microsoft, and Flowdock.

A common post-mortem template will contain some key details like:

when it happened
who owns the post-mortem (and will do the analysis)
some lessons learned
a rough timeline of the emergency bug and some actions from the post-mortem

So let's dive in.

Google

If you did a Google search between 6:30 a.m. PST and 7:25 a.m. PST on January 31st, 2009, you would have seen the message "This site may harm your computer" accompanying every single result.

What happened?

Google flags search results with this message if the site is known to install malicious software. This is a warning to protect Google users, and is collated with Google's automatic algorithms, manual data entry, and a non-profit called StopBadWare.com.

One of the developers had updated the list and accidentally entered in a /, which resolved to every single site!

We know this one was human error, and because of this, Google implemented some tests and checks whenever that file changes. (And I haven't seen it happen again since 2009!)

The full post-mortem can be found here.

Microsoft

Microsoft had a 12 hour outage on February 29th, 2012.

What happened?

Microsoft have Fabric Controllers which are computers that control around 1,000 servers. It manages their life cycles, monitors their health, and restarts servers when they go down.

Isolating all these servers into 1,000 server clusters helps them keep modularity and keeps failures localized to 1 Fabric Controller (rather than all of their servers going down).

Each server in the cluster has something called a Host Agent, and this is used by the Fabric Controller to do the work it deems necessary. One of the things it handles is deploying SSL certificates to keep the servers using HTTPS, which is a way of encrypting data.

To know when these SSL certificates need to be re-generated, they take the next day at midnight and add one year. So if the Fabric Controller is creating a new certificate for a server on March 19, 1990 it will expire March 20, 1991.

Do you see where this is going? These servers attempted to generate a one year certificate for a server on a leap year. It was trying to set the certificates to expire on February 30th, 2020.

When the certificates fail to generate for the server, it terminates. And if it terminates three times in a row, it's considered to be a hardware failure, and then tells the Fabric Controller it is faulty.

The Fabric Controller, in an attempt to "heal" the failed server, will hand over the work to another server. One by one, all the servers will error out while trying to generate these certificates. And this eventually shuts down the Fabric Controller (with it's 1000 servers!).

This disaster resulted from faulty code. There are better ways to handle date problems like leap years and time-zone differences.

The full post-mortem can be found here.

Google, take two

From Thursday August 13, 2015 to Monday August 17, 2015, there were some errors on Google Cloud services, along with permanent data loss on 0.000001% of some hard drives.

What happened?

There were four successive lightning strikes on the local electrical grid that sent power to Google's computers powering Google Cloud services.

There were systems that began to immediately replace the power that was taken out by using a battery backup. Alongside manual intervention from Google employees, the service was restored with minimal permanent loss.

Google has an ongoing program of upgrading their infrastructure so that they are less susceptible to issues like this. After this, they ran analysis covering electrical distribution, software controlling the Cloud services, and the Cloud hardware being used.

The full post-mortem can be found here.

Flowdock

Flowdock instant messaging became unavailable for roughly 32 hours between April 21st and 22nd 2020. Weird behavior was also spotted, like some users not being able to log in. Also, some people found users from another organization in their organization (like Amazon employees cross-contaminated Microsoft, for example).

What happened?

Coronavirus caused a sudden spike of people working from home, which led to a higher than usual usage of Flowdock. This caused very high CPU usage and caused the database to hang whilst trying to deal with the load. There was also some permanent data loss.

The full post-mortem can be found here.

Things to keep in mind when doing a post-mortem

I read a fantastic article by Adrian Hornsby, a Principle Developer Advocate from Amazon. In it, he discussed some things to avoid, and things to emphasize in order to write the best post-mortem if you are ever the owner of one.

Here are some things he suggested:

Don't do post-mortems to blame people, teams, or organisations. Instead, focus on the process(es) that failed to allow these mistakes to cause mischief. Never do a post-mortem to punish someone. There's no value in that, and you won't find improvements.
Don't assume events that happened were more predictable than they were. Only because they've happened are they now obvious. (Hindsight bias)
Make sure you go deep enough. Don't just say we saw an error in the front end code. Really dig deep into the specific error and the conditions that led to it. How can the process catch this next time? A better QA process? More peer reviews? Better error logging?
If your resolution steps to stop it from happening are really vague like "improve documentation" or "train better", you don't understand it clearly enough to be more specific. Make these resolution steps actionable and concrete.
Try and keep your resolution steps to things that can be done in the short term. We are trying to stop these from happening again as soon as possible. Post-mortems can spawn longer term process changes, but that's not what you're focusing on at the moment. Don't try to re-architecture something fundamental or try to change the language some huge codebase is written in.
Let your post-mortem challenge what your team currently believes to be true. Don't assume because everyone believes something to be true that it is (Common belief fallacy)

How to learn more

If you enjoyed this, you can find more public post-mortems here. These include post-mortems from the companies we have already discussed along with examples from Amazon, GitHub, Linux, Heroku, Spotify, Valve, Cloudfare, Etsy, GoCardless, Travis CI and more.

Conclusion

I hope this has explained what a post-mortem is in the software development lifecycle, how to effectively write one, and common mistakes that happen when you write your first few.

Kealan Parr
www.freecodecamp.org

Category

IT Consulting

TQM vs. Kaizen vs. Six Sigma: what’s the difference?

admin — Fri, 09 Sep 2022 03:52:19 +0000

TQM vs. Kaizen vs. Six Sigma: what’s the difference? admin Fri, 09/09/2022 - 10:52

TQM, Kaizen, and Six Sigma are all unique management approaches that have a shared focus on processes rather than projects and value continuous improvement— let’s examine where they differ.

Six Sigma

Six Sigma focuses almost exclusively on the number of defects per million and reducing them. The percentile success rate is the north star. It lays out a concrete framework for finding production problems.

First, you must recognize that the issue exists. Your managers may have an idea that production is too slow. Next, you prove that the problem exists using measurement and data. Then you figure out the solution by running different numbers and using that to find a practical approach.

Kaizen

The Kaizen approach has more in common with TQM as it also aims to improve the work environment as a whole, rather than honing in on defects. Neither Kaizen nor TQM limits itself to fixing mistakes in the production line. The difference is that Kaizen focuses on bottom-up culture-based changes.

TQM

TQM is almost more of a cultural initiative than a management framework with concrete steps. You can see that in the high-level principles like fact-based decision-making where you involve every employee. Where it differs from Kaizen is the focus on high-level management involvement for decisions like standardizing frameworks and tools throughout the company.

Via monday.com

Category

Total Quality Management

Difference between Quality and Grade

admin — Wed, 31 Aug 2022 08:05:47 +0000

Difference between Quality and Grade admin Wed, 08/31/2022 - 15:05

The terms "quality" and "grade" are often used interchangeably. In this post, let's understand the difference between these two terms

Difference between Quality and Grade:

Quality is an attribute that describes how well something works. It is often measured by its performance against specifications. In contrast, the grade is a measure of the relative value of different products or services.

What is Quality?

Quality is the degree to which a product or service meets customer expectations at any given time. A quality system focuses on meeting those expectations to maintain or improve customer satisfaction.

The formal definition of quality as per ISO 9000 2015 is:

"Quality: degree to which a set of inherent characteristics of an object fulfils requirements".

What is a Grade?

Think of grade as a category of the product. Different grades of the products have the same functional use but different technical characteristics.

Here is the formal definition of grade according to ISO 9001 2015:

Grade: "category or rank given to different requirements for an object having the same functional use". Example: Class of airline ticket and category of hotel in a hotel brochure.

Examples

For example, a $1 Raymond pen and $1000 Montblanc pen are both used to write. As long as both are serving this purpose satisfactorily, both have good quality.

However, the Montblanc pen is a separate category of luxury products. Hence it is a different grade or product.

So next time, when you have to compare the quality of the $1 Raymond pen and $1000 Montblanc pen, don't say that the Montblanc pen is of better quality. It is just a different grade or category. You can not compare apples and oranges.

Bad Quality, Good Quality and Grade

Also, high grade does not imply high quality.

Via TIGO Solutions

Category

Total Quality Management

Why does Test Scenario save time and money than Test Case?

admin — Thu, 21 Apr 2022 16:50:55 +0000

Why does Test Scenario save time and money than Test Case? admin Thu, 04/21/2022 - 23:50

Software testing is one of the fundamental components of a software development project which help determine whether a software program or application meets the business requirements or not.

It is sort of an investigation performed on the system to identify any loopholes, gaps or indiscrepancies in the program. There are many approaches to testing.

Test cases and test scenarios are the two important aspects of software testing used to determine requirements of a project and evaluate possible outcomes to test the functionality of the application. We discuss the two in brief and highlight the key points comparing the two in detail.

What is a Test Case?

Test cases are one of the most important parts of a software development life cycle which is responsible for feasibility of the program. It’s a detailed document that consists of a set of variables and conditions to determine whether the program or application is compliant with the business requirements and it’s working as it was originally established to perform. A test case includes a detailed documentation consisting of everything from prerequisites, inputs, and preconditions to testing procedure, expected results, and post conditions. This is a set of conditions designed originally by the tester or the QA team and further reviewed by the analyst to check the feasibility of the project.

What is a Test Scenario?

Test scenario is a collective set of test cases, sort of scenarios which determine the positive and negative aspects of the project to evaluate possible outcomes in order to identify the potential flaws in the program. It is the next level of software testing that involves a number of steps incorporated to ease the work of test cases. It’s more like a test procedure with multiple test cases which help test the program for potential bugs and errors in order to make sure the end-to-end functionality of the program is working fine as expected. Unlike test cases, they are less descriptive intended to provide the specific idea of evaluating a test case rather than getting into the details.

Difference between Test Case and Test Scenario

Definition of Test Case and Scenario

A test case is a document consisting of a set of variables and conditions under which the feasibility of a software application is to be pre-determined in order to verify its functionality. It helps testers to determine whether an application or a system is functioning as it was supposed to function as per client’s requirements. If test case is the “how”, then test scenario is the “what”. It is a sequence of many test cases that need to be executed one after another to check the functionality of the application.

Prerequisites for Test Case and Scenario

Prerequisite is the basic requirements of a project to run the test cases before moving forward with the software application. Test scenario comes at a later stage. Test cases are all about documentation which includes everything from preconditions, test case names, input conditions, and test data to expected results, test parameters, post conditions, and actual results. Test scenario is the next level which includes determining requirements, finding problems in the requirements or design, understanding business and functional requirements, and evaluating test results.

Process of Test Case and Scenario

A test case is a single executable test that begins with a few steps performed one at a time to test the desired output in order to verify if the system behaves as it is required to behave. Generally, it begins with the QA team writing the test cases to determine the feasibility of the design and then the team decides who should be doing the testing, on a case-by-case basis. A test scenario is nothing but a test procedure which is a set of test cases built by the tester on the basis of business requirements. Test scenarios are then reviewed by the business manager or the business analyst who has a thorough understanding of the business requirements.

Importance of Test Case and Scenario

A descriptive step-by-step set of instructions flowed by inputs or conditions and expected results is what a tester need to prepare comprehensive test plans and write test cases. It is required for an effective performance of the application and to make sure the system functions flawlessly without any indiscrepancy. It is one of the most important aspects of software testing used by the quality team, development team as well as the management. It is necessary when the development is happening onsite and testing is happening off-shore which would keep them in sync. Test scenarios replace test cases when time is of the essence and there is no time to build test cases.

Value of Test Case and Scenario

A full-proof test case has a significant impact on the testing phase and is almost as important as testing itself in order to avoid any uncertainties. It is beneficial for new testers as well as for your team and is also a good source of how a software application or its features will behave. This makes sure the objective is fulfilled and the system is fully compliant with the client’s requirements. Test scenarios in the modern age are an independent test or a series of tests that follow each other to make sure the business workflows are in sync with end users’ expectations.

Test Case vs. Test Scenario: Comparison Chart

Summary Test Case vs Scenario

In a nutshell, test cases are one of the important aspects of software testing which help build and evaluate test scenarios to make sure the software or application works flawlessly in the real world. In software testing, both terms are synonymous with each other and while one cannot coexist without the other, a test scenario has a significant relationship with a test case. However, in the modern agile era, test cases seem to be replaced by test scenarios to save time and money for both the development team and the business analyst or the end users. In short, test cases are a sub-set of test scenarios whereas the latter is functionality based and is all about work flow.

Source: differencebetween

Category

IT Outsourcing

The Kaizen Approach to Software Development

admin — Fri, 03 Dec 2021 13:34:21 +0000

The Kaizen Approach to Software Development admin Fri, 12/03/2021 - 20:34

The technology industry works on a continuously evolving mechanism, with new advancements every day. While many product development companies are more focused on producing results, a few actually believe in the importance of creative practices in the organization.

The Japanese word ‘kaizen’ means a business philosophy of continuous improvement is working practices. A healthier practice is for businesses to invest in the improvement of the process and people rather than the end product, which is bound to give better results.

The Kaizen Model

Companies are evolving their processes of making products, preferring to use agile development to save time. Also, with agile, the increasingly popular approach is of the Kaizen model which companies are adopting. The model involves software development companies to encourage employees to develop new skills and focus and learning and improvement rather than just delivering.

The approach first originated in Japan in which everyone must continually evaluate his or her work at each step helping them with a chance to look back and understand where they could have done better. The Kaizen approach proves to be more collaborative giving every individual a way to become smarter employees.

Advantages of the Kaizen Model

1. Reduction in Costs:

As employees review their work at every step, they detect errors and shortcomings at the right time. Traditionally reviews were done at the almost end of the cycle, meaning in case of errors the software development services team needs to work from scratch all over again.

2. Smarter Employees:

Regular evaluation and feedback encourages the team members to interact and share knowledge with one another resulting in a smarter workforce which is open to innovation.

3. Enhanced Quality and Efficiency:

Reviews from peers and seniors tend to establish a healthy competition among employees which, with encouragement from management, boosts up performance quality and efficiency. The approach focuses on employee and their skills which converts into better delivery of services and products.

Implementation of the Kaizen Model

The model can be integrated with software development in many ways. A few are mentioned below:

1. Daily and Special Meetings

Set up a schedule for team meetings to discuss opportunities and improvement. Every employee must be inspired to come up with their share of problems and solutions which the team can get to know. This knowledge sharing platform can address many difficult issues within the company and help create better strategies in the future.

2. Individual and Team

Another sub-concept comes into play here, known as Teian. According to this, each individual must come forward with a proposal of improvement which can be applied after deliberate discussions within the team. This includes the improvements one should make to their personal self. The ultimate goal is continuous improvement which must be achieved.

3. Process of work

Kaizen cannot be implemented on the whole process but on components of it or the sub-processes. Working upon the sub-processes indirectly improves the whole work model, thus, delivering a better product than ever before.

The key to get this model work is encouragement. If an employee reviews his shortcomings and a works his way through them, encouragement is crucial. Only then he and others will want to work dedicatedly towards the common goal, serving the client in the best possible way.

Via octosglobal

Category

Methodology

Machine learning Model Validation Testing

admin — Wed, 02 Jun 2021 16:04:41 +0000

Machine learning Model Validation Testing admin Wed, 06/02/2021 - 23:04

What is Model Validation Testing?

Model Validation Testing is the procedure of evaluating the wellness of models performance against the real data. It is essential that the model validated by considering the aspects and the components before introducing them into the production ecosystem.

Validation – The process of developing an appropriate model.
Verification – The process of developing the model appropriately.
Calibration – The loop process of comparing the model to the real system and doing the changes accordingly.

How does Model Validation Testing work?

There are large numbers of ways estimating the quality of the aspects and the components of a model –

Divide the available dataset into two subsets; these subsets train dataset and test dataset so that the accuracy calculated on the predictions obtained by the model.

The different ways used to provide validity using statistical measures to detect the complications in the respective model or the data.

Business Intelligence ways included in the examination of the output of the model to determine if the exported results have an understanding in the actual business environment.

You would also love to explore our blog based on how Automated Testing on DevOps work.

Benefits of Model Validation Testing

Initial Detection of Deficiencies and Errors- With the testing powered by Model Validation testing, it is easy to detect the deficiencies and errors before Model verification.

Reducing the Costs – It is easy to cut different types of costs as Model Validation testing analyzes the defects so that it can be neglected.

Discovering more Deficiencies and Errors – If defects neglected, it’s recognized as soon as possible.

Enhancing the Quality of the Model – Enhancing is post process of discovering more deficiencies and errors.

Provides scalability and Flexibility in the process of software development – With proper implementation of Model Validation Testing, the edge of scalability and flexibility submitted to the process.

Analysis of the Data and Information related to the Model – The data is the backbone of the model and with the help of validating model testing the proper interpretation of the data and information can be done.

Why Model Validation Testing Matters?

Machine Learning models, Deep Learning models, and other Data Science models are like wizards to generate the correct output if the exact question asked to these wizards. But how the trustworthiness provided to these models. That is where Model validation testing comes into play.

It provides trusted results generated by these models by a mathematical and logical comparison with the actual output.

Model Validation testing performs at the edge of tweaking the model to try different test and training data and checks the validity of the model in a looping manner.

The process of validity automated, it’s a big advantage to check the trustworthiness of Artificial Intelligence model.

How to Adopt Model Validation Testing?

The techniques to perform Model Validation testing are –

Resubstitution – Using all the data for training the model, the validity of the model evaluated by comparing the output value with an actual value which belongs to the same training dataset. The error, in this case, is known as the Resubstitution error and the technique is known as Resubstitution Validation technique.

Hold-out – For avoiding the above-stated resubstitution error. The best way is to divide the dataset into training and test dataset. The ratio can be 80/20, 70/30 or 60/40. This method creates an edge off to the likelihood in the contrast of the uneven distribution of different classes. To cope up this situation, the dataset divided into equal instances of classes in both the datasets.

K-Fold cross-validation – Dataset is divided into K number of subsets where K-1 subsets for training and the rest one subset for testing the model. This method provides an advantage that the model checker for the validation K times.

Bootstrapping – This is the continuous replacement technique in which the dataset for training selected randomly and the instances of the dataset which are not selected are used as a testing dataset. The main difference between this technique and K-fold cross-validation is the value of fold which is likely to change every time.

LOOCV – In this method, only one record used for testing and the rest of other records are used training. The entire data used for training and testing.

Random subsampling – The number of subsets selected and then combined to form a super subset used for testing and the rest of the data used for training.

Classification Matrix – This matrix consists of main numbers in respect for elements which are truly positive, true negative, false positive and false negative with the help the values which calculate – Accuracy, Precision, Recall, and F1-score.

Scatter Plot – This is a graphical representation of the value predicted concerning the actual values. It calculates the accuracy of the model.

Best Practices of Model Validation Testing

Model Validation Testing is a different kind of testing. Conventional testing and Model validation testing are different. Best Practises of Model Validation Testing are –

Dividing the data into testing and training sets.
Dribbling the models by checking the validity for the different combinations of the training and test sets with the same source of data.
Performing various cross-validation methods on the different sets of data sets.
Developing the Classification Matrices to make an inside view on the validity of the model in mathematical view.
Drawing a scatter plot is a good option to check the validity of the model fitted on the regression formula.
Drawing the profit charts with financial costs associated with the model analyzed.

Source: xenonstack

Category

IT Consulting

Quality Management

How to use quality gates to guide IT projects?

Understanding quality gates

Unlocking the gates

Tags

Benchmarking and Software Benchmarks

What is software benchmarking?

Software benchmarking process

Tags

Ishikawa (fishbone) diagram in software project management

An overview of the Ishikawa diagram

Kaoru Ishikawa 11 Points

How does a Ishikawa diagram work?

When should the Ishikawa diagram be used?

Easier Root Cause Analysis for Remote Teams

Tags

Is gold plating good or bad in project management?

Effects of Gold Plating

What’s the difference between Gold Plating and Scope Creep?

Why is gold plating a problem?

Conclusion

Tags

What is a Software Post-Mortem?

What is a post-mortem?

Why should we do a post-mortem?

Let's look at some post-mortems together

Google

What happened?

Microsoft

What happened?

Google, take two

What happened?

Flowdock

What happened?

Things to keep in mind when doing a post-mortem

How to learn more

Conclusion

Tags

TQM vs. Kaizen vs. Six Sigma: what’s the difference?

Six Sigma

Kaizen

TQM

Tags

Difference between Quality and Grade

Difference between Quality and Grade:

What is Quality?

What is a Grade?

Examples

Tags

Why does Test Scenario save time and money than Test Case?

What is a Test Case?

What is a Test Scenario?

Difference between Test Case and Test Scenario

Definition of Test Case and Scenario

Prerequisites for Test Case and Scenario

Process of Test Case and Scenario

Importance of Test Case and Scenario

Value of Test Case and Scenario

Test Case vs. Test Scenario: Comparison Chart

Tags

The Kaizen Approach to Software Development

The Kaizen Model

Advantages of the Kaizen Model

Implementation of the Kaizen Model

Tags

Machine learning Model Validation Testing

What is Model Validation Testing?

How does Model Validation Testing work?

Benefits of Model Validation Testing

Why Model Validation Testing Matters?

How to Adopt Model Validation Testing?

Best Practices of Model Validation Testing

Tags