-
Notifications
You must be signed in to change notification settings - Fork 0
Test Strategy
- What kind of test to automate?
- What tools to use to automate them?
- How to mange the test fixture?
- How to ensure that the system is easy to test?
- How the tests interacts with the SUT?
- to deliver IT system with known and excpected quality
- to freqent find out the quality of the IT system
- to keeping the cost of testing to a minimum.
- to obtain immediate feedback on the business risks associated with a IT system.
- to validate a application
- to maintain a application
- to eradicate defects
- All has the responsibility of quality
- All team members is encouraged to develop an understanding of the requirements and what testing is required.
- All team members is supported to perform testing, through exploration or by executing test automation.
- All team members responds to problems rapidly, whether reported by an individual or by the CI/CD pipeline.
- The test automation tools that are use should bee using should automate in the same language as development
- The test automation tools should be integration in the development environment.
- The test automation tools should be easy to to integrate in the CD/CI pipleline
- Use Open Source Tools should be the first choise before COST tool. Make tools self is the last solution.
- The test automation tool should
- be use in by many.
- has a large community that develope the tool,
- good documentaion,
- good tutorials and courses
- good support
- often relase of new features
- Use peer reviews of our proposed changes to gain whatever assurance is needed that our changes will operate as designed.
- All team members automate as much of the quality checking, that typically performed by a QA or Information Security department ,as possible.
- Instead of team members needing to request or schedule a test to be run, these tests can be performed on demand by every team members, enabling team members to quickly test their own code and even deploy those changes into production themselves.
Automated tests should be:
- Concise—As simple as possible and no simpler.
- Self Checking—Test reports its own results; needs no human interpretation.
- Repeatable—Test can be run many times in a row without human intervention.
- Robust—Test produces same result now and forever.
- Tests are not affected by changes in the external environment.
- Sufficient—Tests verify all the requirements of the software being tested.
- Necessary—Everything in each test contributes to the specification of desired behavior.
- Clear—Every statement is easy to understand
- Efficient—Tests run in a reasonable amount of time.
- Specific—Each test failure points to a specific piece of broken functionality; unit test failures provide “defect triangulation”
- Independent—Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.
- Maintainable – Tests should be easy to understand and modify and extend.
- Traceable—To and from the code it tests and to and from the requirements.
All code shod be coved by black box testing #Practices ATDD/BDD/TDD
System Test
These test should be develope in a cooperation beween stakholders and team members. Automated in same programming language as use for developmemt.
These test should be develope in a cooperation beween stakholders and team members Exeutable Spesification
API testing is a type of software testing that involves testing application programming interfaces (APIs) directly to determine if they meet expectations for
- functionality
- reliability
- performance
- security
Functional testing is simply a test of functions in the API . These functions is tested in scenarios to ensure that the API fullfill the API spesification.
Contract Tests Component Test Unit Tests
Static Test Measure Code Quality
- Test strategy must be adapted to the teams competence.
- What skills and experience have the team members and stakholders?
- Who need the automation and why?
- What goals are you trying to achive?
- What is the greatest area of pain?
- What is the greates area of bordom?
- Can you get code deployed in order to test it?
- Do team members feel confident about changing the code?
- Start automation where there is bigest pain?
- How do we balance the need for automation with the costs?
- Dose the tool provide the result you need right now?
- Dose it provide an adequate return of the resources needed ti use it for automation?
- Are everyone on the team happy with them?
- Are you missing problems because you dont have the right tools?
- What resources is needed for implementing and use of the tool?
- What impact will the tool have on productivity and velocity?
- What risk dose it pose?
- What will it allow you to do that in the long term that cant do now?
Continuose Integration running a robust test suite of unit tests is the first test toward automating other tests. Code that continually refactor for maintainability will help increase the ROI of automation. Refactoring cant happend without good unit test coverage. To find out the coverage one need a
Choises of tools is strategic descitions. To use the tool one needs huge investments in skill building. Once many test is written convering to a new tool needs huge investments. If the team is new to agile development,or working on a brand-new software product, you might be faced with choosing tools and setting up tests enviroment during the early iterations, when you also mitght working with high-risk stories. Dont expect to be able to deliver much buisness value if you are still creating your test infrastructure. Plan in lots of time for evaluatong tools, setting up build process, and experimenting with different test appoaces. Automate tests should be scripted not recorded. As much as possible of the application should be tested in API not trough the GUI.
Compare to test that are recorded and/or test throu GUI are scripeted API test tools:
- Robust
- More Manitainable
- Can be prebuild
- Simple and cheap tools
- More skill required
- Open Source Tools
Compared to recording gui test tools are Scripte GUI tests toolds:
- Somwhat more fragile than API scripted test tools
- Higher maintance costs scripted test tools
- More skilled required than recoding gui tools
- Can be prebuild
- GUI is the API
- Mostly open source tools
- Make it easy for developers to write write tests without needing to learn a new programming language.
- Make it easy to test individual class and objects without having the rest of the application available
- Make it easy to run tests or many test in a single action
- Minimise the cost of running tests so progreammer are not discourace from running the existent tests.
The test tools should be used in the
- Frontend
React
Javascript
backend
Spring Boot Java API REST Gradle as build tool Travis CI server Github Pulumi
The test tool should use Java or Javascript as their script language Mastering on tool at the time Use the right tool for each need. The different test types need different tools. Want to maximise the test types that has the best ROI. Testability is dependent of the system architecture. If the system architecure is desinged for testability will the test automation be less expensive. Test that go through the GUI usally have the lowest ROI, because they are expensive to maintain.
Acceptance tests at API level are not as inexpensive to automate as unit-level test and provide feedbakc a bit more slowly. With the right tool allow them to have a goog ROI. The fact that thees test is written in a language that the stakholders understand add to their value.
Measure Code Quality SonarCloud
Refactoring Eclipse Refactoring
Static Testing
Eslint Checkstyle
Code coverage measurement Logging Store of test result for
Jacoco Jest Covarag?
Unit Test Use of Scripted test Sping Boot Test Junit Mockito
React Test Lib Jest Jest Mock
Integration Test/Social Unit Test Spring Boot Test Junit
API Test
Rest Assured
Cucumber/Java
System Test / GUI Selenium, Jets, JavaScript
Formal Training On The job Training Retrospective/ Continuose Improvment Use of enginering sprints for evaluation Spike