How to Structure Tests for Agile Environments
How to Structure Tests for Agile Environments
If you're moving from a Waterfall model to an Agile model, should you be structuring your tests differently? In this post we take a look at the differences and one tale of such a restructuring.
Join the DZone community and get the full member experience.Join For Free
For the past month, I’ve been in Switzerland implementing Tricentis Tosca for a new customer who is changing their entire software development process from Waterfall to Agile. Within the first week, I had to estimate what would be involved in testing a system that I still barely understood, and commit to what we could test within the next 10 weeks. The rest of my team was very new to the system as well, making it more difficult to understand all the system components, as well as the processes that were necessary for testing.
The first lesson learned was that, within the new environment, it was impossible to test everything end-to-end from a business perspective. The solution was to do two different types of tests for two different business processes:
- For one type of test, we executed the classic end-to-end testing using Tricentis Tosca Risk-Based Test Case Design and Templates.
- For the other, we executed end-to-end component tests, which are technical rather than business-readable tests. The component tests use Tricentis Tosca Test Case Design and Templates as well, but not within every component and test case.
To implement the classic end-to-end test within the Agile team, I had to understand the process completely and define what possibilities we needed in order to test it. I decided to use Test Case Design again and worked through mock-ups by talking to the business experts and developers within my team to find out what my options were.
After the Test Case Design was finished, the developers were ready to show me their UIs. I began by scanning the UI elements and building out the modules we needed. I also worked on the structure within the test cases.
After the modules were finished, I jumped right into creating the test cases and sorting them into execution lists. Once the developers had finished their implementation, the test cases were ready for execution.
For the second set of tests, I implemented component tests. Based on what the developers were implementing, we instantly created test cases to validate if the user stories were properly implemented. This involved connecting to RabbitMQ, RESTful services, databases, and development tools. By running through this process with component tests, I got rid of some nasty issues related to test data. Using component tests, it is possible to pass data directly and does not require accounts in special states. This is a more Agile way of running tests.
To wrap up, I want to spend some time describing the structure of the common repository and how it could look within an Agile environment.
Below the root, I created three Component folders: one 01_Regression, one 02_PI Structure (PI=Program Increment), and one 00_Archive. The first folder contained all the data relevant to the regression test. The PI Structure folder contained everything for the current PI (in Sprint folders), and the Archive folder contained test cases and data which were no longer needed.
Within the Requirements section, you can implement different views for different perspectives. For me, the most relevant were: System – view for my product, Application – view for every application, and Sprint – view for the current Sprint (Product – Epic – Story) within the PI Structure. Depending on your environment, it could make sense to add a fourth folder with all the Applications to store your test cases the right way (otherwise you could put them into the regression folder). This depends on the environment, tester, and team.
The Sprint folders contain, in my case, test cases, requirements, test case design (if needed), and execution lists. After each PI (or Sprint) the regression team checks the “regression relevant” execution list (we have two of execution lists – regression relevant and Sprint only), then adds the green test cases to the regression folder and to the correct execution list for the application. The Sprint-relevant information is then moved to the archive since it is no longer relevant. To save data storage and time within your common repository, exclude the archive and irrelevant data from synchronization. This way, the data within the folder doesn’t need to be loaded until it is needed.
Hopefully, this post helped show you how to work with Tricentis Tosca in an Agile environment and gave you some ideas on how to test components and functions within your applications. How do you work within Agile teams? I would love to hear about your Agile journey! Please feel free to share in comments below.
Published at DZone with permission of Maximilian Bauer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.