DevMate is becoming Vizitest - a brand new way to do Unit and Integration testing!!
You will be redirected to Vizitest.com in 10 seconds
Go to Vizitest.com nowIf you are looking for DevMate Documentation, press the button below.
DevMate DocumentationOr you can go to the DevMate home page.
DevMate HomeHow DevMate works
Helping the whole Product team
DevMate generates test code automatically and that's a big win. However, DevMate helps Developers, QA Engineers and Product Owners easily visualize each test now or years later.
DevMate generates unit and integration tests, but it also helps share the responsibility of test case definitions with the rest of the product team.
You'll be delighted to know that you don't need to change your development configuration at all. Develop in your preferred IDE and no need to work with special test runners or other "magic" tools.
Developers will spend up to 50% less time configuring tests and more time on functional coding.
DevMate will change the way you and your team think about testing. We facilitate not just unit and integration testing, but a requirements led approach that brings structure, drives serious quality and can involve the whole team, not just developers.
As one of Europe’s top Software Quality Management consultancies, we can support your team not just with DevMate services but also a broad range of Software Quality and Process Management services.
The highest quality levels are achieved by making sure that tests are properly requirements led. Requirements are often best understood by domain experts, product managers, product owners and QA Engineers.
DevMate lets the broader product team share responsibility for quality by encouraging them to be involved in the requirements and test case definitions.
Supported Technology
Quality related services and support from one of Europe's leading consultancies.
Over 300 companies trust our sister company Software Quality Lab to deliver the highest quality training on DevMate, Test Automation, Management & Process, Agile, Requirements Modeling, Code Quality and Project Management.
Equations for success
Writing lots of unit tests says little about actual quality. What matters is writing great unit tests. Blindly unit testing everything frustrates developers, requires more maintenance and leads to testing not being taken seriously.
Black Box Testing done well leads to better code quality, less time writing unnecessary unit tests, more time writing functional code and, as a result, improved developer happiness.
When time is tight, we often see only one Happy Path unit test for a given method.
This is rarely adequate as there are typically many paths, some of them critical, that should be covered by tests.
If only the Happy Path is covered by unit tests, this shifts the testing responsibility to higher levels in the testing pyramid (Integration and End to End /UI tests). The net effect is that errors inevitably get through to the customer.
A requirements led, black box approach is usually the best way to deliver high quality tests and therefore high quality.
A lot of companies we talk to focus heavily on code coverage. But this says nothing about whether the requirements are really being properly tested and so is a very unreliable indicator of quality.
TDD or Black Box Testing involves POs and Domain Experts which means less time wasted writing potentially meaningless tests or missing important test cases.
Read our article Obsessed with Code Coverage?
White box testing can be very important in certain situations. However, white box tests can usually only be implemented by a developer as the functional code needs to be fully understood first. And a White Box Test does nothing to confirm whether the requirements are being met.
Black box testing is, in most cases, a better way to go because it is fully requirements led. This also allows the developer to share responsibility for test definitions with Domain Experts, POs and QA Engineers who anyway best understand the requirements. Developers will spend more time writing functional code and less time writing unit tests as a result.
We often see companies not making this connection clearly. If you are following TDD principles then you are, by definition, performing back box tests and are focusing on requirements.
As black box testing approaches are important for validation of the code (does the implemented code meet the requirements?), TDD and Black Box Testing are essentially synonymous.
Of magic and asymmetric relationships
