1. Programų testuojamumas
Stanislavas Guk

2. Testuojamumo apibrėžimas
“Software testability is the degree to which software artifact (i.e. a software system, software module, requirements or design document) supports testing in a given test context” © Wikipedia;
“Attributes of software that bear on the effort needed to validate the software product” © ISO.
„The quality of a software design that allows for automated testing in a cost- effective manner. The end goal of testability is to create rapid feedback cycles in your development process in order to find and eliminate flaws in your code.“© Microsoft
Kas yra programų testuojamumas?

3. Why Testability Matters?
Economics:
Sooner is better.
Higher testability > More better tests.
Lower testability > Fewer weaker tests.

4. Testuojamumo kriterijai
Controllability
Observability
Operability
Simplicity
Stability
Understandability
Decomposability
Kokie yra testuojamumo kriterijai?

5. Controllability
The better the software is controlled, the more the testing can be automated and optimised.
All possible outputs can be generated through some combination of input in Software Testing
All code is executable through some combination of input in Software Testing
Software and hardware states can be controlled directly by testing
Input and output formats are consistent and structured in Software Testing
Tests can be conveniently specified, automated, and reproduced.
Kas yra Controllability (kontroliavimas) kriterijus?

6. Observability Kas yra Observability (stebėjimo sistema) kriterijus?
1. What is seen is what is tested
2. Distinct output is generated for each input
3. System states and variables are visible or queriable during execution
4. Past system states and variables are visible or queriable (eg., transaction logs)
5. All factors affecting the output are visible
6. Incorrect output is easily identified
7. Incorrect input is easily identified
8. Internal errors are automatically detected through self-testing mechanism
9. Internally errors are automatically reported
10. Source code is accessible
Kas yra Observability (stebėjimo sistema) kriterijus?

7. Operability
1. The better the software works, the more efficiently it can be tested.
2. The system has few bugs (bugs add analysis and reporting overhead to the test process)
3. No bugs block the execution of tests.
4. The product evolves in functional stages (allows simultaneous development & testing)
Kas yra Operability (veikimo) kriterijus?

8. Simplicity
1. The less there is to test, the more quickly it can be tested in Software Testing
2. Functional simplicity
3. Structural simplicity
4. Code simplicity
Kas yra Simplicity (paprastumo) kriterijus?

9. Stability
1. The fewer the changes, the fewer the disruptions to testing
2. Changes to the software are infrequent
3. Changes to the software are controlled in Software Testing
4. Changes to the software do not invalidate existing tests in Software Testing
5. The software recovers well from failures in Software Testing
Kas yra Stability (stabilumo) kriterijus?

10. Understandability
1. The more information we have, the smarter we will test
2. The design is well understood in Software Testing
3. Dependencies between internal external and shared components are well understood.
4. Changes to the design are communicated.
5. Technical documentation is instantly accessible
6. Technical documentation is well organized in Software Testing
7. Technical documentation is specific and detailed
8. Technical documentation is accurate
Kas yra Understandability (supratimo) kriterijus?

11. Decomposability
1. By controlling the scope of testing, problems can be isolated quickly, and smarter testing can be performed.
2. The software system is built from independent modules
3. Software modules can be tested independently in Software Testing
Kas yra Decomposability kriterijus?

12. Testability of Requirements
Testable requirements are essential for the testing process, not only because test engineers must predict the expected outcome of their tests, but also tester must verify the results of each test. These activities cannot be done with pre-specified test requirements. It must be measurable and observable. Measurable means that the test engineers can qualitatively or quantitatively verify the test results against the test requirement's expected result.
What does measurable mean in testable requirements?

13. Why Is It Important to Have Testable Requirements?
It is very important to have testable requirements in software projects. The reason is it helps to reduce development time by avoiding expensive software bugs in later stages of the software development life cycle.

14. The Price to Correct a Software Bug
The price of correcting a software defect is lowest in the requirements stage. The reason is there are not so much deliverables at the start of a project to fix if a defect is detected.
As soon as the project moves into posterior stages of the development of software product, the price of correcting a bug increases extremely, since there are more deliverables influenced by the fixing of every bug, such as a design document or the code itself.
Kokia yra „bugų“ ištaisymo kaina?

15. The Price to Correct a Software Bug
Stage
Cost Ratio
Requirements
1-3
Design
3-6
Coding
10-12
Unit Testing
15-40
Acceptance
30-60
Testing
Production
>10000

16. Testability of Requirements
Requirements need to fulfill the following criteria in order to be testable:
consistent
complete
unambiguous
quantitative (a requirement like "fast response time" can not be verification/verified)
verification/verifiable in practice (a test is feasible not only in theory but also in practice with limited resources)
Kokius kriterijus turi atitikti testuojamumo reikalavimai?

17. How improve software testability ?
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

18. Test-driven development (TDD)

19. Test-driven development (TDD)

20. Test-driven development (TDD)

21. Mocking Best Practices
Fake objects come in many different flavors. Most of the examples in this column use stubs—simple objects that provide pre-canned answers and return values. Another type of fake is a "mock" object that is used to record or validate the interaction between classes. Mocks are one of the most valuable—but confusing and misused—concepts in automated testing. 
Kaip veikia fiktyvūs objektai?