Test Designing: Part 3 of our series on the software testing life cycle!
Here we go! Post #3 on the SLTC! If you’re just now joining please catch up by checking out the first post of the series.
Software Testing Life Cycle Requirements and Design Review.
PixelRocket Presents: Software testing life cycle part 3 – Test Design.
This stage of the STLC can certainly sound straightforward, but we’re here in part to dispel some of that myth. Yes, this phase involves coming up with the tests to be acted on and consider all possible applications and edge cases. However, there are methods which certainly add some complexity, and in turn thoroughness, that is much needed.
When folks think of the test design stage the white box and black box methods usually come to mind. These approaches or methods describe a test engineers point of view when he’s designing a test or test cases.
White Box Testing in the Software Testing Life Cycle
White box testing goes by a couple different names such as clear box testing, structural testing, etc. The important part to know, however, is that this form of testing relates to the internal features of the software as opposed to the user-facing features. Test cases are designed with the perspective of the internal system in this form of test design.
If you’ve read our post on unit testing you may be familiar with some of these concepts already. If not, that’s okay! White box testing and unit testing, as well as integration and system test level of testing, can come together in this phase of the software testing life cycle. The white box tests can include tests on the API (public & private), fault injection method testing which is used to measure a feature or unit’s ability to respond to certain failures, and more.
Black Box Testing in the Software Testing Life Cycle
The black box method. PixelRocket Presents: Software testing life cycle part 3 – Test Design.
On the other side of this coin is, as you might expect, the viewpoint of knowing nothing about the internal structure of the program. Testers are only aware of end user-facing features, and care little for how these features operate. There are a multitude of ways to “Black Box Test” a system. Some are summarized below:
- Equivalence partitioning: this technique involves dividing input data of a software unit into separate partitions of equal data and then distilling that data into tests.
- Boundary value analysis: this method involves designing tests to include representatives of boundary or perimeter type data.
- Fuzz testing/Fuzzing: Fuzzing can be automated or semi-automated, concerns throwing invalid, random or unexpected values at a system.
Something a little closer to what goes on in testing cycles at PixelRocket however is specification-based testing. The goal here is to test functions within relevant requirements. Our test teams provide very detailed requirements for the tests and then the test becomes very binary from there. Either the program performs as expected, or otherwise with results binary values in our case. Again, these test cases are still very external-level meaning we only test on what an application should do given an environment or use-case with little concern on how it gets done.
Finally, the nice benefit to this black box method is that it really requires very little programming knowledge to be effective on the test team. The software testing life cycle is not solely contained to the CS majors of the world and the test teams especially have to be able to test, at times, with a bit of a blind eye on the structure of a feature. In fact, it is almost an enormous benefit to know very little on programming with this method in order to keep test designs/specs simple and, more importantly, repeatable.
Interested in how we used Unit Testing and part of the STLC in an actual project? Read our case study on Family Services!
UX and the Software Testing Life Cycle
UX plays an important role in test designing!
A final point to cover on this phase of the STLC is on user experience. It is critical not just to account for functionality in testing software features, but also in the UI/UX, especially for mobile. With guidelines and standards coming from Apple that can prevent applications from ever reaching the store because buttons are off, navigation doesn’t follow best practices, and more. Good QA teams these days need to be more aware of the importance of design when it comes to software and how it can impact the end user, as well as that user’s learning curve.
In the vein of test designing, then, make sure your teams are accounting for the look & feel of your applications and programs. This will ensure that even if the features are all working appropriately the end user can make the best use of those features. It will also, hopefully, ensure that your mobile apps for iOS will make it into the app store with little to no friction.
Deliverables of the Test Design Phase
Finally we come to the deliverables of this test design stage. Test cases and test data are essential here. Outlining what tests you’ll be covering, recording them appropriately and, finally, recording the results of those tests. Following the steps and methods above should make this easier, but the goal is always to be thorough. Delivering these scripts/cases and results is critical to ensuring all teams are on the same page moving forward with functionality.
And that’s a wrap! Here’s what’s next in our miniseries on the Software Testing Life Cycle!
- Part 4 – Test Environment Setup
- Part 5 – Test Execution
- Part 6 – Test Reporting
- Part 7 – Software Release!
About PixelRocket
PixelRocket builds custom web and mobile applications for startups, enterprises and nonprofits. We also focus intensely on the UI/UX of every application we construct, which means a quicker learning curve and better experiences for your users. For the web, we provide solutions in .NET, PHP, and Java, as well as front end design and development. For mobile, we build applications for Apple, Android, and Windows Mobile. Our mission is give you the tools to succeed, and set your business apart.
