Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Smidig 2016 - Do you trust your test?
- 1. Smidig 2016 @chaugstvedt Cecilie Haugstvedt, Test lead Do you trust your tests? Does your customer?
- 2. Manual testing takes time @chaugstvedt
- 3. Automate all the tests!* @chaugstvedt *Terms and conditions may apply
- 6. Sometimes the numbers alone are OK @chaugstvedt
- 7. 7 Unit Tests Integration and API Tests UI Exploratory Tests @chaugstvedt
- 8. 8 @chaugstvedt < = >
- 10. 10
- 11. 11 @chaugstvedt
Editor's Notes
- Hi, my name is Cecilie. I work as a test lead at Computas. To facilitate faster deliveries we need to reduce the time spent on manual testing. In order to do this, we need to know that we can trust the automated tests. Do you trust your tests? Do your customer and the business side trust your tests? How can we build this trust?
- Manual testing takes time
- So what is the solution? Automate all the tests? Well, not all…
- This illustration shows test pyramid concept developed by Mike Cohn. There’s two parts to this illustration I want you to notice: one is that manual testing stilll has its part. However, it is not the topic of this talk. The second part I want you to notice is the need for automation at different levels. Why do we need this?
- Unit tests give fast feedback and allow developers to change, refactor and build new code without being afraid of breaking stuff. They also also allow customers to see that the quality of the system is good and not deteriorating.
- The business side does not really need to understand your unit tests and how your code is working under the hood. They need to know that they are there and that whatever you are delivering are not destroying the quality of your code.
- UI tests are not the same as end-to-end tests. At their best they can be the only way to achieve some realistic coverage of a legacy system without a solid test base. Another advantage of these tests are that they are typically well understood by the business side and funded in business processes.
- At their worst: UI tests are brittle, expensive to write, and time consuming to run. Less is more, at least for a while. A high number of UI tests can become expensive to maintain. Remember: The goal is not to test every part of the available UI but to show that the major value chains are still up and running.
- Testing at the service layer is where you can combine the advantages of unit and UI tests. API and integration tests are faster to run than UI tests and show that the building blocks of the system fits together. If done right, these tests can also show the business side that they have the functionality they want and thus reduce the need for automated UI tests and manual testing.
- If you want to remove the need for the business side to manually test the changes you are making you need to write tests that are readable for the business side. Tests written in C# and Java do not fulfill this criteria. Behaviour Driven Design frameworks such as Cucumber or SpecFlow let you write tests that the business side can read through to verify that you have understood the problem.
- To sum up: Testing is not only about verifying that the code does what you want it to do. Both you and your customer need to trust your automated tests if you are to reduce or eliminate the need for manual testing. In order for your customer to trust the tests they need to be able to read them. If you want to speed up the test process and avoid the more brittle and time-consuming UI tests you need to make sure your service layer tests are readible for the business side