Change Details

>>! In T28110, @kalali wrote: > All tools have to check for the following usage scenario: > > - segmentation on a 3D image > - 3D segmentation (static) on a 4D (dynamic) image > - 4D segmentation on a 4D image > - All this with an image which time geometry does not start at 0 ms (e.g. MITK-Data/3D+t-ITKIO-TestData/LinearModel_4D_arbitrary_time_geometry.nrrd) > > What the segmentation should look like/how it is generated must be specified per tool. But for all tools the following post conditions should apply: > > - Tools can be activated, used /confirmed. > - The timestep of the reference image stays the same and is not changed by starting the segmentation. > - Using the tool does not change the geometry of the segmentation (so 3D stays 3D and 4D segs are still 4D segs after the tool usage). > > Extend the segmentation check lists accordingly. > For the multi label segmentation view it is important to test multiple segmentations, even on different layers. Todos for the current release [x] Align the content of the checklist with the latest features of the MITK (only release-relevant features / plugins) [] Find appropriate data for the GUI tests and define them in the checklist [] Use the checklist to test the GUI functionality and open tasks for failed test [] Note down GUI tests that can be automated in the feature (e.g. put into basic module tests)

>>! In T28110, @kalali wrote: > All tools have to check for the following usage scenario: > > - segmentation on a 3D image > - 3D segmentation (static) on a 4D (dynamic) image > - 4D segmentation on a 4D image > - All this with an image which time geometry does not start at 0 ms (e.g. MITK-Data/3D+t-ITKIO-TestData/LinearModel_4D_arbitrary_time_geometry.nrrd) > > What the segmentation should look like/how it is generated must be specified per tool. But for all tools the following post conditions should apply: > > - Tools can be activated, used /confirmed. > - The timestep of the reference image stays the same and is not changed by starting the segmentation. > - Using the tool does not change the geometry of the segmentation (so 3D stays 3D and 4D segs are still 4D segs after the tool usage). > > Extend the segmentation check lists accordingly. > For the multi label segmentation view it is important to test multiple segmentations, even on different layers. Todos for the current release [x] Align the content of the checklist with the latest features of the MITK (only release-relevant features / plugins) [] Find appropriate data for the GUI tests and define them in the checklist [] Use the checklist to test the GUI functionality and open tasks for failed test [] Note down GUI tests that can be automated in the future (e.g. put into basic module tests)

>>! In T28110, @kalali wrote: > All tools have to check for the following usage scenario: > > - segmentation on a 3D image > - 3D segmentation (static) on a 4D (dynamic) image > - 4D segmentation on a 4D image > - All this with an image which time geometry does not start at 0 ms (e.g. MITK-Data/3D+t-ITKIO-TestData/LinearModel_4D_arbitrary_time_geometry.nrrd) > > What the segmentation should look like/how it is generated must be specified per tool. But for all tools the following post conditions should apply: > > - Tools can be activated, used /confirmed. > - The timestep of the reference image stays the same and is not changed by starting the segmentation. > - Using the tool does not change the geometry of the segmentation (so 3D stays 3D and 4D segs are still 4D segs after the tool usage). > > Extend the segmentation check lists accordingly. > For the multi label segmentation view it is important to test multiple segmentations, even on different layers. Todos for the current release [x] Align the content of the checklist with the latest features of the MITK (only release-relevant features / plugins) [] Find appropriate data for the GUI tests and define them in the checklist [] Use the checklist to test the GUI functionality and open tasks for failed test [] Note down GUI tests that can be automated in the feafuture (e.g. put into basic module tests)