TweetFollow Us on Twitter

Software Errors
Volume Number:6
Issue Number:11
Column Tag:Developer's Forum

Software Errors: Prevention and Detection

By Karl E. Wiegers, Ph.D., Fairport, NY

Software Errors: Prevention and Detection

Most programmers are rather cavalier about controlling the quality of the software they write. They bang out some code, run it through some fairly obvious ad hoc tests, and if it seems okay, they’re done. While this approach may work all right for small, personal programs, it doesn’t cut the mustard for professional software development. Modern software engineering practices include considerable effort directed toward software quality assurance and testing. The idea, of course, is to produce completed software systems that have a high probability of satisfying the customer’s needs.

There are two ways to deliver software free of errors. The first is to prevent the introduction of errors in the first place. And the second is to identify the bugs lurking in your code, seek them out, and destroy them. Obviously, the first method is superior. A big part of software quality comes from doing a good job of defining the requirements for the system you’re building and designing a software solution that will satisfy those requirements. Testing concentrates on detecting those errors that creep in despite your best efforts to keep them out.

In this article we’ll take a look at why the issue of software quality should be on the tip of your brain whenever you’re programming, as well as discussing some tried-and-true methods for building high-quality software systems. Then we’ll explore the strategies and tactics of software testing.

Why Worry About Software Quality?

The computer hobbyist doesn’t think much about software quality. We write some little programs, experiment with graphics tricks, delve into the operating system, and try to learn how the beast works. On occasion we write something useful, but mostly just for own benefit. The “quality” of one-user, short-lived programs like these doesn’t really matter much, since they’re not for public consumption.

The professional software engineer developing commercial products or systems for use by his employer has a more serious problem. Besides the initial effort of writing the program, he has to worry about software maintenance. “Maintenance” is everything that happens to a program after you thought it was done. In the real world, software maintenance is a major issue. Industry estimates indicate that maintenance can consume up to 80 percent of a software organization’s time and energy. As a great example of the importance of software maintenance, consider how many versions of the Macintosh operating system have existed prior to version 7.0. Each new system version was built upon the previous one, probably by changing some existing code modules, throwing out obsolete modules, and splicing in new ones.

The chore of maintenance is greatly facilitated if the software being changed is well-structured, well-documented, and well-behaved. More often, however, code is written rather sloppily and is badly structured. Over time, such code becomes such a tangle of patches and fixes and kludges that eventually you’re better off re-writing the whole module, rather than trying to fix it once again. High-quality software is designed to survive a lifetime of changes.

What is Software Quality?

Roger Pressman, a noted software engineering author and consultant, defines software quality like this:

Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

A shorter definition is that a high-quality software system is one that’s delivered to the users on time, costs no more than was projected, and, most importantly, works properly. “Working properly” implies that the software must be as nearly bug-free as possible.

While these are workable definitions, they are not all-inclusive. For example, if you build a software system that conforms precisely to a set of really lousy specifications, do you have a high-quality product? Probably not. Part of our job as software developers is to help ensure that the system specs themselves are of high quality (i.e., that the specs properly address the user’s needs), as well as building an application that conforms to this spec.

A couple of other important points are implied in this definition. One is that you HAVE specifications for the programs you’re writing. Too often, we work from a fuzzy notion of what we’re trying to do. This fuzzy image becomes refined over time, but if you’ve been writing code during that time, you’ll probably find that much of it has to be changed or thrown out. Wouldn’t you rather think the problem through in detail up front, and only code it once? I’ve discovered through years of practice that this approach results in a much better product than if I just banged out the code on the fly.

Another implication is that “software” includes more than executable code. The “deliverables” from a software development project also include the written specifications, system designs, test plans, source code documentation, and user manuals. Specifications and designs might include narrative descriptions of the program requirements and structure, graphical models of the system (such as data flow diagrams), and process specs for the modules in your system.

Software quality impacts these other system deliverables just as it affects the source code. The quality of documentation is particularly important. Have you ever tried to change someone else’s code without being able to understand his mindset at the time he wrote it? Detailed documentation about the parts of the software system, the logic behind them, and how they fit together is extremely important. But erroneous documentation is worse than nothing at all, since it can lead you down a blind alley. Any time the documentation and source code don’t agree, which do you believe?

There’s a compelling economic incentive for building quality into software. The true cost of a software development project is the base cost (what you spend to build the system initially) PLUS the rework cost (what you spend to fix the errors in the system). The rework cost rarely is figured into either the time or money budgets, with the consequence that many projects cost much more to complete than expected and soak up still more money as work is done to make the system truly conform to the specifications. In too many cases, the project is delivered too late to be useful, or not at all.

Software Quality Assurance

Software quality assurance, or SQA, is the subfield of software engineering devoted to seeing that the deliverables from a development project meet acceptable standards of completeness and quality. The overall goal of SQA is to lower the cost of fixing problems by detecting errors early in the development cycle. And if your SQA efforts prevent some errors from sneaking into your code in the first place, so much the better. SQA is a watchdog function looking over the other activities involved in software development.

Here are some important SQA thoughts. First, you can’t test quality into a product; you have to build it in. Testing can only reveal the presence of defects in the product. Second, software quality assurance is not a task that’s performed at one particular stage of the development life cycle, and most emphatically not at the very end. Rather, SQA permeates the entire development process, as we’ll see shortly. Third, SQA is best performed by people not directly involved in the development effort. The responsibility of the SQA effort is to the customer, to make sure that the best possible product is delivered, rather than to the software developers or their management. SQA won’t succeed if it just tells the managers what they want to hear.

Testing is certainly a big part of SQA, but by no means the only part. Testing, of course, is the process of executing a computer program with the specific intention of finding errors in it. It’s nearly impossible to prove that a program is correct, so instead we do our best to make it fail. Unfortunately, most of us perform testing quite casually, without a real plan and without keeping any records of how the tests went.

Proper software testing requires a plan, or test script. It includes documentation, sample input datasets, and records of test results. Instead of being informal and ad hoc, good software testing is a systematic, reproducible effort with well-defined expectations. We’ll talk more about good testing strategies later on.

Now let’s look at some goals of SQA for the various stages of structured software development. No matter what software development life cycle model you follow, you’ll always have to contend with requirements analysis, system specification, system design, code implementation, testing, and maintenance, so these SQA goals are almost universally applicable. For one-man projects, much of the formality of these stated SQA goals is not needed. Instead, try to discipline yourself enough to meet the most important aspects of the goals, while still having fun writing the programs.

Requirements Analysis

• Ensure that the system requested by the customer is feasible (many large projects have a separate feasibility study phase even before gathering formal requirements).

• Ensure that the requirements specified by the customer will in fact satisfy his real needs, by recognizing requirements that are mutually incompatible, inconsistent, ambiguous, or unnecessary. Sometimes needs can be addressed in better ways than those the user is requesting.

• Give the customer a good idea of what kind of software system will actually be built to address his stated requirements. Simple prototypes often are useful for this.

• Avoid misunderstandings between developers and customers, which can lead to untold grief and hassles farther down the road.

Software Specifications

• Ensure that the specifications are consistent with the system requirements, by setting up a requirements traceability document. This document lists the various requirements, and then tracks how they are addressed in the written specs, the system design (which data flow process addresses the requirement), and the code (which function or subroutine satisfies the requirement).

• Ensure that specifications have been supplied for system flexibility, maintainability, and performance where appropriate.

• Ensure that a testing strategy has been established.

• Ensure that a realistic development schedule has been established, including scheduled reviews.

• Ensure that a formal change procedure has been devised for the system. Uncontrolled changes, resulting in many sequential (or even concurrent) versions of a system, can really contribute to quality degradation.

Design

• Ensure that standards have been established for depicting designs (such as data flow diagram models for process-oriented systems, or entity-relationship models for data-oriented systems), and that the standards are being followed.

• Ensure that changes made to the designs are properly controlled and documented.

• Ensure that coding doesn’t begin until the system design components have been approved according to agreed-upon criteria. Of course, we all do some coding before we really “should”; so long as you think of it as “prototyping”, that’s fine. Just don’t get carried away prematurely.

• Ensure that design reviews proceed as scheduled.

Coding

• Ensure that the code follows established standards of style, structure, and documentation. Even though languages like C let you be super-compact and hence super-obscure in your coding, don’t forget that a human being (maybe even you) may have to work with that code again some day. Clarity of code is usually preferred over conciseness.

• Ensure that the code is being properly tested and integrated, and that revisions made in coded modules are properly identified.

• See that code writing is following the stated schedule. It probably won’t be; the customer is entitled to know this and to know the impact on delivery time.

• Ensure that code reviews are being held as scheduled.

Testing

• Ensure that test plans have been created and that they are being followed. This includes a library of test data, driver programs to run through the test data, and documentation of the results of each formal test that has been performed.

• Ensure that the test plans that are created do in fact address all of the system specifications.

• Ensure that, after testing and reworking, the software does indeed conform to the specifications.

Maintenance

• Ensure consistency of code and documentation. This is quite difficult; we tend to not update documentation when we change the programs. However, such an oversight can create nightmares the next time a change has to be made. Can you trust the docs, or not?

• Ensure that the established change control process is being observed, including procedures for integrating changes into the production version of the software (configuration control).

• Ensure that changes made in the code follow the coding standard, are reviewed, and do not cause the overall code structure to deteriorate.

By now you’re saying, “Yeah, right. No way, man. Can’t be done.” To be honest, most professional software engineers DON’T follow nearly this stringent a quality plan. Unfortunately, the result of having no SQA plan at all often is software of low, perhaps unacceptable, quality. If you can incorporate even a few of these SQA goals into your own development activity, you should see some real improvements. I certainly have.

Making SQA Happen

There are three principal SQA activities:

1. The creation and enforcement of standards, practices, and conventions.

2. Conducting and keeping records on project reviews.

3. Independent test case design and execution (independent of the guy writing the code, that is).

I’ll assume that you’re already practitioners of standard methods for high-quality software system design. By this I mean that you’ve selected methods and tools that suit your needs for structured analysis and design, such as data flow diagrams, data dictionaries, and process specifications. And of course I assume that you all practice good structured programming techniques. We’ll spend some time on software testing methods later on this article. Now let’s look at the powerful tool of reviews, or walkthroughs.

Reviews

Many software engineering authorities believe that the single most effective SQA activity is to hold structured reviews or walkthroughs at key stages of the development process. The review process involves collecting several pairs of skilled eyes, besides those of the developer, into a room and scrutinizing the deliverables from a particular phase of system development The purpose of the review is to find errors. It has the additional benefit of educating your associates about your project, which can be valuable if the members of a software development group ever have to do maintenance on systems they didn’t build (the usual real-world case).

I like to schedule reviews or walkthroughs at these points during development: after the requirements specification has been completed; after overview design is complete (usually a data flow model); after detail design is complete (process specifications for individual modules); after the test plan is written; and after coding has been done. I always include the primary customer representative (“project champion”) in the requirements and overview design reviews.

The specific topics covered during an SQA review depend on the nature of the deliverables produced. For example, you’ll do things a little differently if your specification document is a written narrative or if it includes a data flow model of the problem being addressed. Reviews of specifications and overview designs should examine data flow diagrams and data models for consistency, proper balancing between levels, and accuracy and completeness of the data dictionary. During the detail design review, structure charts and process specs are examined for errors and inconsistencies. Along the way, make sure that all of the requirements from the specification phase are being satisfied.

A code review checks for the presence of all the features described in the process specification for the module being studied. Again, you should look for inconsistencies with the data dictionary and other design documents. The code should be checked for quality of structure, documentation, completeness, complexity, and clarity. Look for the characteristics of well-structured modules, with high cohesion (performing a single task) and low coupling to other modules.

Each step of the review should check all deliverables against the formal standards you agreed upon at the outset of the project. This includes system and code-level documentation. It doesn’t matter so much exactly what standards you’ve selected, so long as your development products adhere to them. Consistency is much more important than dogma here.

Test Case Design

Let’s turn our attention to software testing techniques. Testing is the second level of error control: detection. Don’t confuse testing with debugging, which is the third step in error control. The goal is to find the problems, not necessarily to resolve them at this time.

Historically, testing has occupied the greatest fraction of the time and effort associated with software development. A big reason for this is the lack of attention traditionally paid to system specification and design. Of course, you could test any program until doomsday and still not be completely sure that it will work right 100% of the time. But if we use thorough, structured test procedures, we can have more confidence that we’ve eradicated most of the bugs from the final product.

The testing process begins with development of a testing plan. In principle, this can be done by either the software developer (you), or by an independent testing person or group. The difference is that the developer has a conflict of interest: he wants to demonstrate that the program works properly, while the independent tester wants to find the flaws in the software. The best compromise is to have the developer handle unit testing and have somebody else address integration and acceptance testing. We’ll talk more about these different test phases shortly.

The bulk of the test script should be written prior to the coding phase. This may seem silly to you, but I’ve found it to work very well. One of the hardest aspects of software development is for the system designer to share the customer’s vision of what the end product will be and do. The person who writes the test script has to visualize how the software is to behave whenever a particular set of inputs is received or a particular action specified. This rigorous thought process helps greatly to uncover any fuzziness or errors in the design plan. It also helps to catch any oversights in going from system specification to system design. Once when I was writing a test plan, I couldn’t remember writing the process narratives that would implement two functions I needed to test. Sure enough, I had overlooked those requirements. The test plan helped me catch my errors and correct them very early in the system development effort.

Your test script should include a bunch of individual tests that specify particular input values and action selections, and the expected results of the program execution under those conditions. Specify values for inputs that cover these situations: the smallest and largest allowable numbers; missing entries; values out of the legal range; random legitimate values; and incorrect data types. Design test paths that will ensure that each statement in the code is executed at least once. Make sure that your error-handling routines work right, and that your validation of input data catches all the sorts of errors that might realistically be encountered.

Similarly, devise tests for logical control flow constructs (IF/ELSE IF/ELSE, CASE/SELECT, etc.) to make sure that each conditional branching statement is executed at least once in every possible direction. You can’t possibly cover every possible combination of paths through even a very small program, but you should convince yourself that control is transferred properly in each individual branching statement. Loops should be tested with conditions that will produce 0, 1, and the maximum possible number of iterations, as well as a typical number of iterations in between the extremes.

The fundamental purpose of writing a test plan is to be able to reproducibly run your software through a wringer and see how it performs. The task of executing all these tests is simplified if you can build a library of test data files and sample output for comparison. Anything you can do to automate the testing process will save time and avoid human errors. This can be difficult with programs having a strong emphasis on user interface. One possibility is to use a tool to capture keystrokes and mouse clicks and build a library of macros that simulate specific sequences of human activities.

Testing Strategies

We can think of two different aspects to testing a piece of software. First, does the software properly perform its intended functions? And second, is the structure of the code free of syntax and logic errors? This is the dichotomy of “functional” versus “structural” testing. The customer is concerned with the first case; he doesn’t care what the code looks like, so long as it does the job. He thinks of the program as a black box: he supplies the inputs, and by some magical process he gets the desired outputs back. The developer is concerned about the structure and flow of his code; to test it properly, he must study the code and devise tests in accordance with the way the program is written. These two aspects of software testing are called “black box” and “white box” testing, respectively.

White box testing typically is performed by the developer. It is a unit- or module-level testing process, in which tests are devised to evaluate the program logic and internal control flow of each individual subroutine or function in the system. Black box testing is performed by the independent testers we discussed earlier, as well as by the customers. Black box testing focuses on the proper handling of supplied inputs to generate the expected outputs.

If you review the topics that I suggested your test script should include, you’ll see a mix of structural and functional aspects described. The customer is the ultimate judge of whether the software meets his stated requirements. But it’s the developer’s responsibility to guarantee that the code is properly written so as to trap errors, handle both valid and invalid input data, and transfer control properly.

System Integration and Integration Testing

Let’s assume you’re working on a software project with a few dozen separate modules. Your unit-level testing has convinced you that they are all well-behaved and properly coded. Your next problem is to assemble all these modules together into the final system, in accordance with the program architecture you devised during system design.

There are basically two ways to approach the process of system integration and integration testing. You can pull the modules all together in one fell swoop, cross your fingers, and offer sacrifices to the compiler gods. This is called “big-bang” integration, and it’s almost guaranteed to fail. Or, you can use an incremental approach of joining modules into small clusters and testing the clusters as you go. This technique is superior, and it will cost you much less money for aspirin.

The incremental integration approach can use either a top-down or a bottom-up method, although in practice a combined “sandwich” method often works best. With a top-down strategy, you begin with the highest-level control modules and add one lower-level module at a time. After each module is added, you perform appropriate tests to see that the fusion went properly. The most likely source of errors is in the data interface between each pair of modules. The bottom-up technique begins by clustering your lowest-level modules (where the real work gets done) together, testing the clusters for proper behavior, and working your way up until the whole functional processing cluster is joined to the high-level control modules.

The problem with any integration strategy is that you need to simulate the presence of certain modules before you’ve actually incorporated them. With top-down integration, you must simulate the presence of low-level modules by using “stub” modules. These stubs are replaced one at a time by their actual counterparts. The stubs must have a certain amount of functionality built in so that they can fake out the higher-level modules into thinking that they are the real thing. Stubs can show simple trace messages to indicate when control is properly passed into the lower-level module, and they can display any passed parameters to demonstrate whether the data interface is functioning correctly. Stubs may also have to return some data, either real or simulated, to the calling module to allow execution of the cluster you’re now testing to continue.

Similarly, the clusters you’re testing in a bottom-up approach aren’t designed to function without the higher-level modules attached, so you have to use temporary “driver” modules to get the program to execute. The drivers can simply invoke the top-level module in the cluster you’re now testing, or it can pass in some parameters both to test the data interface and to allow the cluster to do its thing and return some results to the driver.

Neither top-down nor bottom-up integration is perfect, so you may want to select some combination strategy for your individual projects. The method you choose may be based on where you expect to have the most problems. If control is complex and processing simple, top-down offers the advantage of testing the control modules first. If the data interface between your system and the outside environment is a big issue, bottom-up may be the best approach. In general, drivers are more complex than stubs, so you may have to do a little more work if you use a straight bottom-up method.

Testing isn’t complete just because you think you’ve integrated all your modules properly. It’s very important to perform an overall system test to look for additional errors that didn’t crop up during the unit testing or integration process. Also, acceptance testing by the users is essential to see if the final product does in fact match the stated requirements. For more discussion about these and other aspects of software testing, see the books listed in the references.

The Bottom Line

The overall message from this article is that software quality is a vitally important issue in modern software development, and that there are well-defined methods for assessing and improving the quality of the programs you write. I’ve used these methods, and I believe in them. To my way of thinking, SQA efforts are every bit as important as any other aspect of the software engineering process. If you take away only one thought from this article, please take this one: Quality cannot be tested into software; it can only be designed in.

References

1. Roger S. Pressman, Software Engineering: A Practitioner’s Approach, 2nd Edition, McGraw-Hill, 1987.

2. Boris Beizer, Software Testing Techniques, Van Nostrand Reinhold, 1983.

3. Boris Beizer, Software System Testing and Quality Assurance, Van Nostrand Reinhold, 1984.

4. Glenford J. Myers, Software Reliability: Principles and Practices, John Wiley & Sons, 1976.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Tunnelblick 3.8.2a - GUI for OpenVPN.
Tunnelblick is a free, open source graphic user interface for OpenVPN on OS X. It provides easy control of OpenVPN client and/or server connections. It comes as a ready-to-use application with all... Read more
calibre 4.17.0 - Complete e-book library...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital librarian... Read more
MacPilot 11.1.4 - $15.96
MacPilot gives you the power of UNIX and the simplicity of Macintosh, which means a phenomenal amount of untapped power in your hands! Use MacPilot to unlock over 1,200 features, and access them all... Read more
Transmission 3.00 - Popular BitTorrent c...
Transmission is a fast, easy, and free multi-platform BitTorrent client. Transmission sets initial preferences so things "just work", while advanced features like watch directories, bad peer blocking... Read more
Doom 3 1.3.1 - First-person shooter acti...
A massive demonic invasion has overwhelmed the Union Aerospace Corporation's (UAC) Mars Research Facility, leaving only chaos and horror in its wake. As one of only a few survivors, you must fight... Read more
Box Sync 4.0.8004 - Online synchronizati...
Box Sync gives you a hard-drive in the Cloud for online storage. Note: You must first sign up to use Box. What if the files you need are on your laptop -- but you're on the road with your iPhone? No... Read more
LibreOffice 6.4.4.2 - Free, open-source...
LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more
Day One 4.14 - Maintain a daily journal.
Day One is an easy, great-looking way to use a journal / diary / text-logging application. Day One is well designed and extremely focused to encourage you to write more through quick Menu Bar entry,... Read more
MenuMeters 2.0.7 - CPU, memory, disk, an...
MenuMeters is a set of CPU, memory, disk, and network monitoring tools for Mac OS X. Although there are numerous other programs which do the same thing, none had quite the feature set I was looking... Read more
War Thunder 1.97.2.19 - Multiplayer war...
In War Thunder, aircraft, attack helicopters, ground forces and naval ships collaborate in realistic competitive battles. You can choose from over 1,500 vehicles and an extensive variety of combat... Read more

Latest Forum Discussions

See All

SINoALICE, Yoko Taro and Pokelabo's...
Yoko Taro and developer Pokelabo's SINoALICE has now opened for pre-registration over on the App Store. It's already amassed 1.5 million Android pre-registrations, and it's currently slated to launch on July 1st. [Read more] | Read more »
Masketeers: Idle Has Fallen's lates...
Masketeers: Idle Has Fallen is the latest endeavour from Appxplore, the folks behind Crab War, Thor: War of Tapnarok and Light A Way. It's an idle RPG that's currently available for Android in Early Access and will head to iOS at a later date. [... | Read more »
Evil Hunter Tycoon celebrates 2 million...
Evil Hunter Tycoon has proved to be quite the hit since launching back in March, with its most recent milestone being 2 million downloads. To celebrate the achievement, developer Super Planet has released a new updated called Darkness' Front Yard... | Read more »
Peak's Edge is an intriguing roguel...
Peak's Edge is an upcoming roguelike puzzle game from developer Kenny Sun that's heading for both iOS and Android on June 4th as a free-to-play title. It will see players rolling a pyramid shape through a variety of different levels. [Read more] | Read more »
Clash Royale: The Road to Legendary Aren...
Supercell recently celebrated its 10th anniversary and their best title, Clash Royale, is as good as it's ever been. Even for lapsed players, returning to the game is as easy as can be. If you want to join us in picking the game back up, we've put... | Read more »
The Magic Gladiator class arrives in MU...
The Magic Gladiator class is now available in MU Origin 2 following the most recent patch. It also marks the start of Abyss Season 11 and the introduction of Couple Skills and Couple Dungeons. [Read more] | Read more »
The 5 Best Racing Games
With KartRider Rush+ making a splash this past week, we figured it was high time we updated our list of the best mobile racing games out there. From realistic racing sims to futuristic arcade racers (and even racing management games!), check out... | Read more »
KartRider Rush+ Guide - Tips for new rac...
KartRider Rush+ continues to be a surprisingly refreshing and fun kart racer that's entirely free-to-play. The main reason for this is just how high its skill ceiling is. Check out the video above if you're curious to know what top level play looks... | Read more »
KartRider Rush+ might be good, actually?
It's hard to find good racing games on mobile. Most of them are free-to-play, and free-to-play racers generally suck. Even Nintendo couldn't put together a competent Mario Kart game, opting instead for a weird score chaser that resembles--but feels... | Read more »
LifeAfter, NetEase's popular surviv...
A new map will be making its way into NetEase's popular survival game LifeAfter. The map is set to arrive on May 28th and will introduce a volcano that's teetering on the verge of eruption, bringing a host of added challenges to the game. [Read... | Read more »

Price Scanner via MacPrices.net

Apple restocks 2019 MacBook Airs starting at...
Apple has clearance, Certified Refurbished, 2019 13″ MacBook Airs available again starting at $779. Each MacBook features a new outer case, comes with a standard Apple one-year warranty, and is... Read more
Apple restocks clearance Mac minis for only $...
Apple has restocked Certified Refurbished 2018 4-Core Mac minis for only $599. Each mini comes with a new outer case plus a standard Apple one-year warranty. Shipping is free: – 3.6GHz Quad-Core... Read more
Apple’s new 2020 13″ MacBook Airs on sale for...
B&H Photo has Apple’s new 2020 13″ 4-Core and 6-Core MacBook Airs on sale today for $50-$100 off Apple’s MSRP, starting at $949. Expedited shipping is free to many addresses in the US. The... Read more
B&H continues to offer clearance 2019 13″...
B&H Photo has clearance 2019 13″ 4-Core MacBook Pros available for up to $300 off Apple’s original MSRP, with prices starting at $1149. Expedited shipping is free to many addresses in the US. B... Read more
Memorial Day Weekend Sale: Take $300 off thes...
Apple resellers are offering $300 discounts on select 16″ MacBook Pros as part of their Memorial Day Weekend 2020 sales. Prices start at $2099: – 16″ 2.6GHz 6-Core Space Gray MacBook Pro: $2099 at... Read more
Best Memorial Day Weekend 2020 Apple AirPods...
Apple resellers are offering discounts ranging up to $50 off MSRP on AirPods as part of their Memorial Day Weekend 2020 sales. These are the best deals today on various AirPods models. See our... Read more
Memorial Day Weekend Sale: 10″ Apple iPads fo...
Amazon is offering new 10.2″ iPads for $80-$100 off Apple’s MSRP as part of their Memorial Day Weekend 2020 sale, with prices starting at only $249. These are the same iPads sold by Apple in their... Read more
Memorial Day Weekend Sale: 2020 Apple iPhone...
Sprint is offering Apple’s new 2020 64GB iPhone SE for $0 per month for 18 months as part of their Memorial Day Weekend 2020 sale. New line of service and trade-in required. Offer is valid from 5/22/... Read more
Amazon’s popular $100 Apple Watch Series 5 di...
Amazon has Apple Watch Series 5 GPS + Cellular models on sale for up to $100 off Apple’s MSRP today. Shipping is free. These are the same Apple Watch models sold by Apple in their retail and online... Read more
2020 13″ 4-Core MacBook Air on sale for $949,...
Apple reseller Adorama has the new 2020 13″ 1.1GHz 4-Core Space Gray MacBook Air on sale today for $949 shipped. Their price is $50 off Apple’s MSRP, and it’s the lowest price currently available for... Read more

Jobs Board

Essbase Developer - *Apple* - Theorem, LLC...
Job Summary Apple is seeking an experienced, detail-minded Essbase developer to join our worldwide business development and strategy team. If you are someone who Read more
Senior Software Engineer @ *Apple* - Theore...
Job Summary Apple is looking for a seasoned senior software engineer to join our worldwide business development and strategy team. This is an opportunity to lead a Read more
Cub Foods - *Apple* Valley - Now Hiring Par...
Cub Foods - Apple Valley - Now Hiring Part Time! United States of America, Minnesota, Apple Valley Retail Operations Post Date May 18, 2020 Requisition # 119230 Read more
Senior Practice Manager - *Apple* Hill Eye...
Senior Practice Manager - Apple Hill Eye Center Tracking Code 61713 Job Description Schedule & Location: Full Time Days Apple Hill Medical Center General Read more
Retail Sales Consultant - *Apple* Valley -...
Retail Sales Consultant - Apple Valley - $500 Hiring Bonus Apply Now...12-30-2019 Address : 7875 150th St W Location : Apple Valley, MN US Req # : 272753BR Job Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.