The testing world is big. Here's a little window into our mindset and where we fit in:
Its a brake release spring from a bike. Its small but important because it releases the brake when you release the lever (stops the bike stopping!). You could say its a unit because it has no smaller parts. Its not dependent on any other parts and its easily tested in isolation
Put under specified tension and release
Unit tests verify individual components of a complex system. A unit can be tested independently of the other parts of that system. These tests are cool because they let us know whether each of the the small parts of a system work in isolation
We know the small parts work in isolation
We know which small parts have failed. We can fix them and run again
Unit tests are best written by developers because they are close to the code. The tests can be run quickly and efficiently by computers so its good to have many of them
Here is a brake from that bike
The spring above is part of this brake, but the brake has a lot of other small parts too. A brake is a component of a bike. Any given system has lots of components. There'll likely be components within components, and there will certainly be joining of components. These'll need testing. You may also hear these referred to as functional tests. Integration tests are component tests involving interfaces
Check Breaks Open & Closes When Lever Pulled
Check Break-pads Contact Rim Appropriately
Check Breaks Fixed Properly
Check Break-pads Release Appropriately
Component tests are unsatisfactory in isolation because they neither tell you the whole system works or where exactly something went wrong
This Component works, but what about its interface between component?
Which part of component failed? Lets go back and check the unit test
Unit and component tests come from the inside-out:
driven by knowledge of how the system is built
Here is a system. In our case its a bike
What will a user of this system care about when they want to use it? They'll have regard for what it does (its behaviours!) rather than the parts its made from
Everybody knows what a bike should do - you don't need be a bike mechanic
No need to outline the ways you'd test a bike. You've known these since you were 4 years old
This is where behavioural testing comes in
Behavioural (aka black-box) tests are outside-in:
they don't require knowledge of how the system is built
..like getting in a vehicle and verifying that it drives forward, without knowing what makes it drive..
What we're describing are automated black-box acceptance tests but we call them behavioural because they are produced from a specification by example (ATDD/BDD) process
The power of such tests comes not from independence but from inter-dependence of parts working together. Behavioural tests check the functional contract by exercising the system holistically. If the contract is broken we look under the bonnet at lower level tests
Behaviour is as we specified
Behaviour is not as we specified. Check Component Test
Some may discuss whether to have unit and component tests OR behavioural tests [TDD vs BDD]. This is a misguided notion and you need both. They cover completely different aspects and complement each other beautifully!
What makes Testclub unique?
It may be useful to show examples of questions we'd ask, rather than answers we 'd claim to come with:
What is this project and application about?
What matters most right now?
Who are your users, and what is the context of their use?
Where will automation make productive impact?
Where might automation be less impactful or cause pain?
Identifying problems in software, reducing implementation risks and maximizing user satisfaction.
We implement solutions for test automation in order to achieve a higher efficiency in the continuous release of new versions.
We encourage the release of inclusive software that can be used by people with disabilities.
We evaluate security to look for any vulnerabilities in order to avoid potential cyber attacks threatening the integrity and security of the system.
We evaluate how systems peform, and identify bottlenecks through performance, load and stress testing.
We work together to improve user experience through real user evaluations and tests.
Full QA: Testclub integrated into your team (can white-label) and solving every aspect of your QA
Consulting: Advice on the best principles and processes for building quality into software. Most importantly, applying them to your context
Automation only: Delivering world-class automated tests direct into your repo. Assistance getting them running in CI where required
Defects only: Timely delivery of defect lists for your team to prioritise
Why use a testing agency?
To lay a path for embedded quality processes within your company: proper specification, robust automation, full transparency and traceability. The highest quality products are an emergent result of consistently getting these factors right.
Once we've helped you lay the path, the imparted principles and automation are yours.
Testclub is a network of developers in test which presents via a focal point. When you use resources from a network you tap into the full knowledge of that network. We can bring any framework, any language to bear in the automation we deliver. We implement the right solutions for your application and context.
Testclub focuses on just 3 things:
- Specification: Your system' behaviours documented exactly, as tests. An essential foundation for development and testing
- Defects: Descriptive lists of defects delivered to your development team
- Automation: Specification implemented as automated tests
There is no learning on the job. Just QA pros delivering what you'd hope for from an ideal QA function on any time basis you choose.