Software testing acceptance testing tutorials and videos

Open Source .NET Behavior-Driven Development (BDD) Tools

Software Testing Magazine — Mon, 02 Dec 2024 12:00:13 +0000

Behavior-Driven Development (BDD) is an Agile approach that mixes requirement gathering, documentation and acceptance testing. You write human-readable sentences describing the features of your application and how they should work. Then you implement this behavior using a tool that produces automated acceptance tests to verify that the feature is implemented correctly. Open source .NET BDD tools like SpecFlow are used to store the requirements as live documentation and to perform functional or acceptance tests. This article presents a list of open source software testing tools to perform Behavior-Driven Development (BDD) for the .NET platform and the C# language. For each tool, you will get a small description of its features. Feel free to suggest any additional .NET BDD framework or resource that you think should be included in this article. The tools, listed here are BDDfy, BDD toolkit for .NET, Concordion.NET, Kekiri, LightBDD, Machine.Specifications (Mspec), Nbehave, Nspec, Reqnroll, SpecFlow, SpecsFor, Storyteller, TickSpec, Xunit.Gherkin.Quick. Updates * December 2 2024 removed: xBehave.net (archived) added: BDD toolkit for .NET, Kekiri, Reqnroll, Xunit.Gherkin.Quick BDDfy BDDfy is a simple open source .NET BDD framework that is easy to use, customize and extend. It can run with any testing framework and you can just apply it on your POCO (test) classes. BDDfy doesn’t need a separate test runner. You can use your runner of choice. For example, you can write your BDDfy tests using NUnit and run them using NUnit console. BDDfy is very extensible: the core barely has any logic in it and delegates all [...]

The post Open Source .NET Behavior-Driven Development (BDD) Tools first appeared on Software Testing Magazine.

How To Perform Exhaustive Testing

Software Testing Magazine — Mon, 18 Jan 2021 16:29:27 +0000

Exhaustive testing is a type of software testing approach where all the behaviors of a system are explored during the tests. If this approach is good in theory, it is not feasible in most testing contexts where time and resources are limited. This article presents the distinguishing characteristics of exhaustive testing and explain how to perform it. Author: Nataliia Syvynska, TestMatick, https://testmatick.com/ A good deal of something is not always considered an excellent indicator of quality. Any self-respecting software tester is a true protectionist who always strives to ensure that the software is of the highest quality. It is a good trait, but sometimes it can bring undesired results. To prevent this, it is necessary to become familiar with such a concept as “exhaustive testing”. This material will be a good help in setting professional criteria and methods for drawing up a universal software testing plan. A frequent piece of advice that you can find in articles for aspiring testers is: “You should always test everything you see, using all the methods you know”. From the software quality assurance’s point of view, this approach is not considered bad or wrong, especially when it comes to programs for a nuclear power station or spacecraft. Nevertheless, in the era of widespread commercial testing for a corporate (less often, government) order, with a specific budget, this can become a destructive phenomenon. By increasing the boundaries of the testing field and the number of tests to infinity, a quality assurance (QA) engineer brings the time for these [...]

The post How To Perform Exhaustive Testing first appeared on Software Testing Magazine.

Acceptance Testing for Continuous Delivery

Software Testing Magazine — Mon, 27 Apr 2020 20:34:06 +0000

Writing and maintaining a suite of acceptance tests that can give you a high level of confidence in the behavior and configuration of your system is a complex task. This presentation describes approaches to acceptance testing that allow teams to work quickly and effectively; build excellent functional coverage for complex enterprise-scale systems; manage and maintain those tests in the face of change, and of evolution in both the codebase and the understanding of the business problem. This presentation will answer the following questions, and more: * How do you fail fast? * How do you make your software testing scalable? * How do you isolate test cases from one-another? * How do you maintain a working body of tests when you radically change the interface to your system? Video producer: http://agileindia.org

The post Acceptance Testing for Continuous Delivery first appeared on Software Testing Magazine.

Millisecond Full Stack Acceptance Tests

Software Testing Magazine — Mon, 28 Oct 2019 17:52:55 +0000

Are your full stack acceptance tests slow, non-deterministic and hard to maintain? You’re not alone. Imagine running hundreds of them in a few seconds, giving the same result every time. How do you think a feedback loop that fast would that affect your team’s productivity? This video presents what this workflow looks like. You will learn about the underlying principles and techniques for millisecond full stack acceptance tests. This is primarily a talk for programmers, as the solution to the problem requires refactoring of the system under test as well as tests. I will demonstrate that the basic assumption of the Test Pyramid model are wrong, and suggest a more useful taxonomy of tests, and how to partition testing efforts. Video producer: https://gotoams.nl/

The post Millisecond Full Stack Acceptance Tests first appeared on Software Testing Magazine.

Best Practices Reviewing Requirements for Testability

Software Testing Magazine — Tue, 25 Jul 2017 08:35:34 +0000

In classical (waterfall) project management approaches, the requirements review is an essential gate before starting the actual software development phase. If you participate to these meetings as a software tester, your role is to make sure that the software requirements are testable during the acceptance testing process. In this article, Richard Ellison provides advice on how to handle the requirements validation process from a software testing perspective. Author: Richard Ellison, The QA People, http://theqapeople.com/ “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along wound destroy civilization.” – Gerald Weinberg (American computer scientist) Requirements reviews for complex waterfall projects will probably be the most painfully boring thing you will do in your life. For one week you will sit in a room and listen to people going through misunderstandings that will crop up again and again. The easiest thing will be to tone out and not listen and review the requirements after the fact. Every time I review after the fact, I missed something, an odd expectation was put on the testing team or a non-testable requirement was created with the assumption that it would be tested. The worst scenarios I have run across is questioning the requirements after initial review only to identify that business analyst (BA) does not know what the requirement means and has to go back to the client to identify why we needed this in the list of requirements. A few key points about the requirements review. Your role [...]

The post Best Practices Reviewing Requirements for Testability first appeared on Software Testing Magazine.

Testing in Arquillian with Docker Containers

Software Testing Magazine — Mon, 08 May 2017 13:31:23 +0000

Arquillian is an open source testing platform for the JVM that enables to easily create automated integration, functional and acceptance tests for Java middleware. In this article, Alex Soto presents three options to use Arquillian Cube to manager Docker containers from Arquillian. Author: Alex Soto, http://www.lordofthejars.com/ Arquillian Cube is an Arquillian extension that can be used to manager Docker containers from Arquillian. With this extension, you can start a Docker container(s), execute Arquillian tests and after that shutdown the container(s). The first thing you need to do is add Arquillian Cube dependency. This can be done by using the Arquillian Universe approach: <dependencyManagement> <dependencies> <dependency> <groupId>org.arquillian</groupId> <artifactId>arquillian-universe</artifactId> <version>${version.arquillian_universe}</version> <scope>import</scope> <type>pom</type> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.arquillian.universe</groupId> <artifactId>arquillian-junit-standalone</artifactId> <scope>test</scope> <type>pom</type> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${version.junit}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.arquillian.universe</groupId> <artifactId>arquillian-cube-docker</artifactId> <scope>test</scope> <type>pom</type> </dependency> </dependencies> Then you have three ways of defining the containers you want to start. The first approach is using the docker-compose format. You only need to define the docker-compose file required for your tests, and Arquillian Cube automatically reads it, start all containers, execute the tests and finally after that they stop and remove them. version: '2' services: pingpong: image: jonmorehouse/ping-pong ports: - "8080:8080" networks: app_net: ipv4_address: 172.16.238.10 ipv6_address: 2001:3984:3989::10 front: back: networks: front: driver: bridge back: driver: bridge app_net: driver: bridge driver_opts: com.docker.network.enable_ipv6: "true" ipam: driver: default config: - subnet: 172.16.238.0/24 gateway: 172.16.238.1 - subnet: 2001:3984:3989::/64 gateway: 2001:3984:3989::1 @RunWith(Arquillian.class) public class PingPongTest { @HostIp String ip; @HostPort(containerName = "pingpong", value = 8080) int port; @Test public void [...]

The post Testing in Arquillian with Docker Containers first appeared on Software Testing Magazine.

Software Testing Environments Best Practices

Software Testing Magazine — Mon, 20 Jun 2016 13:54:16 +0000

When you learn to program, everything happens on the same computer, but when you start working for a (structured) organization, you realize the risks of changing and testing code directly where your users or customers are working. Thus you will have separated environments for developing, integrating or releasing your system. In this article, Richard Ellison provides some best practices for software testers on how to manage software testing environments. Author: Richard Ellison, The QA People, http://theqapeople.com/ Code appears in different areas for different reasons and ultimately for different usage. Each environment has a specific purpose and as a tester understanding these environments and can be key to implementation of a successful software testing and quality assurance strategy. I will run through a very high level overview of the most common software testing environments. Do not get concerned if the naming does not match what your organization uses. As long as you have the key understanding of the environments you should be able to get the information you need. Before we review a few best practices around the environment I wanted to offer a quick overview with some initial details on each environment. DEV (Development Environment) – This is the environment the developers will write the code in. Before I say anything about DEV I have to say this to software testers: never test in dev. This is the golden rule. It is right next to don’t let the developers run the test for QA. I did not add this as [...]

The post Software Testing Environments Best Practices first appeared on Software Testing Magazine.

Problems & Issues Acceptance Testing Can Cause

Software Testing Magazine — Mon, 06 Jun 2016 13:54:11 +0000

There is nothing worse than building right the wrong software. Acceptance testing is the activity that allows the customer to validate that the delivered software meets their needs and specifications. If acceptance testing play an important role in validating software delivery, it can also cause some issues as Toby Weston explains it in his book “Essential Acceptance Testing”. Author: Toby Weston, Independent Consultant, http://baddotrobot.com This article is based on the book “Essential Acceptance Testing” published on Leanpub. This content is copyrighted by Toby Weston and reproduced here by permission. Communication crutch The typical acceptance testing process encourages communication but it can also formalise it. It places checkpoints that are designed to ensure that key conversations take place and agreement is established However, it can also encourage the team to focus on these as the only required conversations. If developers find it hard to have conversations with the business, it may be that they’ll make a token effort under the umbrella of “agreeing acceptance criteria” and forgo more meaningful conversations. Hand off behaviour In agreeing acceptance criteria, the whole team (testers, developers and business) should be engaged and collaborating. With discrete steps it can be easy to assign responsibilities to roles and hand off responsibility when your step is done. I’m not sure if this kind of process really encourages collective responsibility. For example, in one team I worked with, testers would speak with the business to define acceptance criteria and draft acceptance tests. These were then handed off to the [...]

The post Problems & Issues Acceptance Testing Can Cause first appeared on Software Testing Magazine.