Our notable partnerships give us access to the best resources and tools for the job.
Get software testing training resources:
Environments (specifically test environments) are collections of hardware, instrumentation, simulators, software tools, and other support elements needed to conduct tests. It’s important to distinguish between the environment and the system under test during defect reporting.
Realizing a solid return on your testing investment requires smart selection of tests. Cost of quality analysis tells us that it’s cheaper to find and fix bugs before the customers do, but, to keep bugs away from customers, we have to find the ones that matter. Doing so requires that we understand how the customers will use the system.
Subtle but catastrophic bugs, such as those that cause server crashes and database record-lock race conditions, often only reveal themselves during performance, stress, volume, data quality, and reliability testing. Such testing is most effectively performed in test environments— hardware, software, network, and release configurations—that mimic as nearly as possible the field environment, because test results in less-complex settings often do not extrapolate due to the non-linearity of software. In complex settings, such as Web and e-commerce server and database farms, managing these lab configurations can be quite challenging. This paper presents a basic Access database, designed using the Entity-Relationship technique, that will allow the Test Manager to plan, configure, and maintain this test environment through the test project.
If you are a software tester, programmer, or manager, you probably know that developing secure software is no longer simply desirable—it’s completely essential.
Some might assume that most security problems arise from the operating system or networking layers, well below the application code they are working on. However, figures for Web-based applications show that over three-quarters of security exploits arose from applications.
So, you know you need secure code, but how to get there? What are your security risks? What security failures and bugs do you have? What do these security risks, failures, and bugs mean? How can you reduce security risk in a way that doesn’t create new problems? How do you monitor my progress over time? This article will outline seven steps that will allow you to answer these and other questions as you improve your software’s security.
This is an excerpt from my book, Expert Test Manager, written with James Rommens and Leo van der Aalst. I hope it helps you think more clearly about the test strategies you use.
A test policy contains the mission and objectives of testing along with metrics and goals associated with the effectiveness, efficiency, and satisfaction with which we achieve those objectives. In short, the policy defines why we test. While it might also include some high-level description of the fundamental test process, in general the test policy does not talk about how we test.
The document that describes how we test is the test strategy. In the test strategy, the test group explains how the test policy will be implemented. This document should be a general description that spans multiple projects. While the test strategy can describe how testing is done for all projects, organizations might choose to have separate documents for various types of projects. For example, an organization might have a sequential lifecycle test strategy, an Agile test strategy, and a maintenance test strategy.
[The following is an excerpt from my upcoming book, Mobile Testing: An ASTQB-BCS Foundation Guide, coming out in summer 2018. This section talks about the important issue of mobile test environments.]
Earlier in this book, I gave the example of my client that gave iPhones to all the sales associates in their stores. Because of that, they have a fairly homogeneous environment. This is true not only of the client-side, but also the connectivity in the stores (through the in-store Wi-Fi installed by them) and the back-end servers in the stores and in their data centers.
In terms of mobile testing, this homogeneity makes them the exception that proves the rule, as the saying goes. They don’t have to deal with widespread and unpredictable environmental diversity. What diversity they do have is due to deliberate decisions. For example, they have to depreciate the iPhones, so over time there came to be multiple generations of iPhones in stores.
Recorded May 18, 2017
Recorded February 16, 2017
Recorded May 19, 2016
Length: 1h 30m 0s
Let’s suppose you bought a car. Six days later, someone from the dealership let himself into your garage, removed the tires on the car, installed some “updated” tires that actually had holes in them, and then left. In the morning, your car was there in the garage, all sad and undriveable on its flat, flabby tires. That’s clearly unacceptable, in fact even criminal, but we allow the same thing to happen all the time with software. Why? In this webinar, Rex will catalog infamous automated software updates, released without sufficient testing to wreak havoc, or at least inconvenience. He’ll then give a detailed roadmap for reducing your chances of being part of the problem.
Length: 0h 38m 45s
If you’ve been testing for any length of time, you know that the number of possible test cases is enormous if you try to test all possible combinations of inputs, configuration values, types of data, and so forth. It’s like the mythical monster, the many-headed Hydra, which would sprout two or more new heads for each head that was cut off. Two simple approaches to dealing with combinatorial explosions such as this are equivalence partitioning and boundary value analysis, but those techniques don’t check for interactions between factors. A reasonable, manageable way to test combinations is called pairwise testing, but to do it you’ll need a tool. In this inaugural One Key Idea session, Rex will demonstrate the use of a free tool, ACTS, built by the US NIST and available for download worldwide. We can’t promise to turn you into Hercules, but you will definitely walk away able to slay the combinatorial Hydra.
Length: 0h 53m 46s
If you are testing a simple mobile app, you may find it relatively easy to find representative test data. However, what if you are testing enterprise scale applications? In the enterprise data center, one hundred or more applications of various sizes, complexity, and criticality co-exist, operating on various data repositories, in some cases shared data repositories. In some cases, disparate data repositories hold related data, and the ability to test integration across applications that access these data sets is critical. In this keynote speech, Rex Black will talk about the challenges facing his clients as they deal with these testing problems. You’ll go away with a better understanding of the nature of the challenges, as well as ideas on how to handle them, grounded in lessons Rex has learned in over 30 years of software engineering and testing.
The Advanced Security Tester Boot Camp course, created by Rex Black, past President of the International Software Testing Qualifications Board (ISTQB), past President of the American Software Testing Qualifications Board (ASTQB) and co-author of a number of International Software Testing Qualifications Board syllabi, is ideal for testers and test teams preparing for certification in a short timeframe with time and money constraints.
The Advanced Test Automation Engineer Boot Camp, created by Rex Black, past President of the International Software Testing Qualifications Board (ISTQB), past President of the American Software Testing Qualifications Board (ASTQB) and co-author of a number of International Software Testing Qualifications Board syllabi, is ideal for testers and test teams preparing for certification in a short timeframe with time and money constraints.