The scatter diagram, or scatter plot, is a type of mathematical diagram of XY coordinates used to display values for a set of data. Typically, one value is under control while the other varies based on our control. For a quality assurance example, our control may be the number of features, while the variable is the number of bugs. The data for a scatter diagram is based over time or experience.
A Pareto Chart allows you to quickly identify the problem areas of your application by reporting those areas that have the greatest number of issues. The philosophy of the Pareto Chart is based on the 80/20 rule – by identifying and fixing the larger areas first, the application can be stabilized a lot quicker. Or, more specifically, correcting 20% of the currently known bugs will stabilize 80% of the application.
A histogram is a very simple diagram and doesn’t take much time to create. It illustrates a data point in history in order to calculate the probability of something happening in the future. In general, if we notice a trend of a event or action happening in a specific period, we can plan for the same event or action in the future, given the same circumstances.
Control charts are used for statistical analysis to determine if a process is in a stable state of control. Control charts are very similar to run charts, except that control charts have additional lines for upper and lower control limits. Control charts help us to determine the effectiveness of our quality control over time and view irregularities in order to improve our control quality.
A stratification diagram, also known as a flowchart or run chart, is used to determine the relationship between two or more sets of data. Stratification diagrams are helpful for making patterns visible when data is coming from a wide variety of sources. These patterns can be compared to the various systems under test so that we can, once again, adjust our processes in order to improve quality.
The check sheet is, by far, the easiest report to produce. The only thing required is an Excel-type application for columns and rows. The header should be a fact for the dimension you are tracking. This fact is usually something like a day of the week, week of the month or another time-based milestone, but it doesn’t have to be. The row dimensions are the defect types you are tracking. So, as an example, let’s say we are tracking defects on a web application that’s under development.
The Ishikawa, or Fishbone, diagram (or, affectionately known as the “Fishikawa” diagram), is one of the easiest diagrams to create. No special software is needed, per se. The content for the Ishikawa diagram is constructed using The 5 Why’s as discussed in the previous post. The answer to each question can be classified under one of six outside factors which makes up a bone from the fish’s scale.
Quality Assurance is not simply measuring the quality of an application. It’s also measuring the quality of your development. More times than not, development teams become so focused on “fixing bugs” that we “miss the forest for the trees” – we don’t stop to assess the quality of the development process. What good are our bug fixes if we simply introduce new bugs into the system? How often are we introducing new bugs? Is there a feature set or an area of the application that seems to have more bugs than other areas? Is a developer more prone to creating bugs? With all of the tools that we have at our disposal, it amazes me how little quality assurance tracks the actual development quality. Instead, we merely have a backlog of bugs which we keep increasing with each new iteration.
Want to $watch an object in Angular, but ignore changes on certain properties? Here’s a function that will help you out:
And here’s how to use it…
And, finally a jsfiddle example.
I’ve been developing a LOT of Angular applications lately. Some of them are hybrid projects (Angular w/ MVC); some of my projects have been completely separated (Angular for client-side, with a separate project for an API). Regardless, I always want to ensure that my code has been thoroughly tested with unit tests and acceptance (E2E) tests. When developing hybrid projects, my preferred IDE is Visual Studio. When developing a pure, client-side project, my preferred IDE is Visual Studio Code as it has a lot less remnants/artifacts tied to a solution (.vs, .xproj, .csproj, etc.) eliminating the need for a ridiculously large .gitignore file. Additionally, I will use WebStorm depending on the need.
Jasmine is a great framework for providing both unit testing and end-to-end, acceptance testing. Coupled with Karma, Jasmine can monitor file changes to our client-side code and execute tests on every file change in order to ensure that all tests are always passing. In this blog post, I will demonstrate how to set up and use Karma and Jasmine in both development environments.
Subscribe to receive new posts in your inbox.