Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'test'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Management
  • Design
  • Requirements
  • Development
  • Test
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-Commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-Commerce
  • Others

Categories

  • Thoughts
  • Debate
  • Health
  • Hobbies

Categories

  • Personligt
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Designs
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Categories

  • Prologue
    • About This Book
  • The Tools
    • Jira Software
    • Confluence
    • Jira Service Management
  • The Inception Phase
    • Portfolio Management
    • Project Management
  • The Design Phase
    • Design as part of the Inception phase
    • Design as part of the Requirement phase
    • Working with design libraries
  • The Requirement Phase
    • Definition of Requirements
    • The four levels of Requirements
  • The Development Phase
    • Atomic design
    • Estimations
  • The Test Phase
    • The Definition of Test
    • Types of Test
  • The Operations Phase
    • Release Management
  • The Post Go-Live Phase
    • Incidents
    • Changes
  • Notes
    • My Muses
    • Research

Categories

  • Theme Building
  • Javascript Framework
  • CSS Framework
  • IPS: Pages
    • Database Templates
    • Block Plugin Templates
    • Page Templates
  • Custom Applications
  • Tips & Tricks

Categories

  • Europe
    • Central Europe
    • Eastern Europe
    • Northern Europe
    • Southeastern Europe
    • Southern Europe
    • Western Europe
  • North America
    • United States of America
    • Canada
    • Mexico
    • Caribbean
    • Central America
  • South America
    • Argentina
    • Bolivia
    • Brazil
    • Chile
    • Colombia
    • Ecuador
    • Falkland Islands
    • Guyana
    • Paraguay
    • Peru
    • Suriname
    • Uruguay
    • Venezuela
  • Africa
    • Northern Africa
    • Central Africa
    • Western Africa
    • Eastern Africa
    • Southern Africa
  • Asia
    • Central Asia
    • East Asia
    • South-Eastern Asia
    • Southern Asia
    • Western Asia
  • Oceania
    • Australia
    • Fiji
    • Kiribati
    • Marshall Islands
    • Micronesia
    • Nauru
    • New Zealand
    • Palau
    • Papua New Guinea
    • Samoa
    • Solomon Islands
    • Tonga
    • Tuvalu
    • Vanuatu

Categories

  • Shared Hosting
  • Virtual Private Server
  • Cloud Hosting
  • Dedicated Hosting
  • Co-Location
  • Hosting Services

Categories

  • Professional
    • Management
    • Design
    • Requirements
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Categories

  • Defects
  • Ideas
  • Development
  • ☑ Archive

Categories

  • Professional
  • Management
    • Agile
  • Requirements
  • Design
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Hosting
  • Atlassian
  • Security
  • E-commerce
    • CRO
    • SEO
  • Interesting

Categories

  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Forums

  • General
    • Open Forum
    • Support
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics
  • Wolcen's Wolcen Topics
  • Quality Assurance Heroes's QA Topics
  • Visual Studio Code's Forum
  • Adobe Illustrator's Adobe Illustrator Forum
  • Sketch Guru's's Sketch Topics
  • Requirements & test management in Jira's Topics
  • Microsoft Teams's Microsoft Teams Discussions
  • Figma's Figma Topics
  • Microsoft Planner's Microsoft Planner Topics
  • Psychology's Psychology Topics
  • Microsoft Word's Microsoft Word Topics
  • Microsoft Powerpoint's Microsoft Powerpoint Topics
  • WordPress Devs's Wordpress Topics
  • Ornamental Design's Ornamental Design Topics
  • Adobe Photoshop's Photoshop Discussions
  • Agile 2's Agile 2 Topics
  • Agile 2's Agile 2 Principles
  • Microsoft Outlook's Outlook Topics
  • My Book's Discussions
  • Outriders's Outriders Discussions

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Invision Power Services
    • JWSE Support Tickets
    • JWSE Task Management
  • Shadownessence's Files
  • WordPress Devs's Wordpress Files

Calendars

  • Project: JWSE Workboard
  • Project: JWSE Workboard
  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events
  • Agile 2's Agile 2 Events

Blogs

  • How to start your own blog
  • Sketch Blog
  • Building The Site's Blog
  • Destiny 2's Destiny 2 ramblings
  • The Journey's Stories
  • Diablo 4's Diablo 4 blog
  • Sketch Guru's's Sketch News
  • Requirements & test management in Jira's News
  • Agile 2's Agile 2 Blog

Categories

  • Personal
    • Humor
    • Music
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
  • Destiny 2's Videos
  • The Journey's Videos
  • Cinephilia's Trailers
  • Diablo 4's Diablo 4 Videos
  • Wolcen's Wolcen Videos
  • Visual Studio Code's Videos
  • Adobe Illustrator's Adobe Illustrator Videos
  • Sketch Guru's's Sketch Videos
  • Requirements & test management in Jira's Videos
  • Microsoft Teams's Microsoft Teams Videos
  • Figma's Figma Videos
  • Microsoft Planner's Microsoft Planner Videos
  • Psychology's Psychology Videos
  • Microsoft Word's Microsoft Word Videos
  • Microsoft Powerpoint's Microsoft Powerpoint Videos
  • WordPress Devs's Wordpress Videos
  • Ornamental Design's Ornamental Design Videos
  • Adobe Photoshop's Photoshop Videos
  • Agile 2's Agile 2 Videos
  • Microsoft Outlook's Outlook Videos
  • Outriders's Outriders Videos

Categories

  • Movies
    • Action Movies
    • Adventure Movies
    • Animated Movies
    • Comedy Movies
    • Crime Movies
    • Drama Movies
    • Fantasy Movies
    • Horror Movies
    • Romance Movies
    • Sci-Fi Movies
    • Thriller Movies
    • Western Movies
  • TV Shows
    • Action TV Shows
    • Adventure TV Shows
    • Animated TV Shows
    • Comedy TV Shows
    • Crime TV Shows
    • Drama TV Shows
    • Fantasy TV Shows
    • Horror TV Shows
    • Romance TV Shows
    • Sci-Fi TV Shows
    • Thriller TV Shows
    • Western TV Shows

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 11 results

  1. Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that. I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled. When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap. Requirements & test management in Jira RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like. The RTM Requirements module This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots. You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not. While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far. The RTM Test Cases Module Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses. As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots. The RTM Test Plans Module Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases. To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up. The RTM Test Executions Module The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently. There are some things I think can be improved visually, but overall this works pretty well. The RTM Defects Module The Defects module give you an overview of the defects in the projects. If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots. The Good and The Bad There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test. Version management What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global. Acceptance Criteria This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing. This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements. Import from other projects One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution. Quickfilters in Defects module The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary. The Module Templates While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters. Better integration with Confluence If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to. Other Apps support Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs. Test Executions UX and Visuals The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view. The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard. Colorful folders This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set. My opinion on RTM from Deviniti This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today. When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance. I like it. A lot.
  2. Magnus Lindblom

    Magnus Lindblom

    Entrepreneur, business developer and manager with experiences from radically improving test organisations and starting, operating and selling restaurant businesses. Specialties: Business and organizational development. Strategic test management in complex environments such as in banking and insurance.
  3. Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that. I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled. When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap. Requirements & test management in Jira RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like. The RTM Requirements module This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots. You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not. While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far. The RTM Test Cases Module Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses. As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots. The RTM Test Plans Module Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases. To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up. The RTM Test Executions Module The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently. There are some things I think can be improved visually, but overall this works pretty well. The RTM Defects Module The Defects module give you an overview of the defects in the projects. If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots. The Good and The Bad There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test. Version management What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global. Acceptance Criteria This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing. This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements. Import from other projects One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution. Quickfilters in Defects module The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary. The Module Templates While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters. Better integration with Confluence If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to. Other Apps support Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs. Test Executions UX and Visuals The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view. The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard. Colorful folders This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set. My opinion on RTM from Deviniti This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today. When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance. I like it. A lot. View full blog article
  4. Michael Karlsson

    Michael Karlsson

    Michael is passionate about test, QA, requirements work and agile a way of working. He is happy to work hands-on as test leader / test coordinator / tester. Michael has worked on developing complex system solutions where quality in business and deliveries are important. In many cases, his work has led to an increased productivity for the test area. Michael is a problem solver where his dedication inspire the team. He like to support others and to share his knowledge. He thrives best when he can combine test management with testing and requirements work in close collaboration with customers and developers. Michael speaks and writes freely in Swedish and English and has extensive experience working in international environments.
  5. Some people say Defect and some say Incident. Both are correct, but what is the difference and why does it matter? In this article I will explain how I see the difference, why it matters and perhaps more importantly when it matters. When it comes to defects, then we have already defined that a defect is when the solution does not fit the requirement. We also defined what a defect is not, so we should be fine with just the term defect. Right? Well, there are actually a few reasons why we should actually have have two different definitions for a defect. The Legal Aspect One of the least understood aspect of defects is the fact that there is a point in the development process that change the way we manage defects. That point is when a solution is accepted, which occur during the acceptance phase before code is deployed and released in production. From a legal perspective this is when the standard agreement between the client and the provider is fulfilled. There might be additional services added beside the standard agreement that add another layer on top of the standard one, like a post go live support period or extended defect management after release. This point in the development is also where responsibilities sometimes shift from the development team to a maintenance team for example. The Complexity Aspect Another important aspect is the complexity aspect that comes into play as the deploy is released into a production system. Even if the pre-prod environment is identical to the production environment it is still withing the development teams responsibility. Once put into production this usually changes and the complexity with the full solution as well as the full network make it a much more costly affair to manage problems. When issues occur in the development teams environments it rarely involve other teams. Problem are managed within the team with the occasional support from surrounding system teams or network teams. Once you go to production however problems often become the affair of many teams. The Workflow Aspect How the team work with a defect is not the same for something found in a production environment, for obvious reasons. In a normal development workflow you can choose what code go to production, but for a defect found in production you do not have that choice. This is why you bypass the normal workflow and use hotfix, which is a fast track to correct problems in production environments. Two ways of working, two types of defects Based on the fact that we do have different processes for a defect found in production and for a defect found in the lower environments we should separate the issues themselves. This is not just to make it easier to identify in for example Jira, but also since there can be differences in who will manage the defect and the process to manage the defect itself. It also allow us to define the defects differently. Defects are problems that prevent acceptance. If there is a defect, then acceptance should not be given. It is a problem that only affect the legal aspects of an agreement. It can cause delays, which in turn can damage the company financially, but it will not affect the end user as it has never been released. By definition a defect is considered an internal problem and solving it involve only the development team within the standard way of workflow. It is simply development not yet complete. The severity of a defect determine when in time it should be fixed based on dependencies withing the project as well as surrounding systems. Defects are considered free since they are part of the development agreement. In Jira a defect is placed inside a development to block it from going into production. Incidents are problems that can damage the company. An incident found in production is available to end user and as such it can cause damage to the company. It can cause disruption of service, it can damage the brand perception or even cause direct impact on sales. Solving this problem often involve multiple teams and it require a separate workflow that disrupt the standard workflow. By definition this is an external problem and it can cause legal issues as it is found after acceptance has been given. The severity of the incident determine when in time it should be fixed based on the damage it causes. Incidents always comes with a cost, which usually is some form of support or maintenance agreement. In Jira an incident is a standalone issue that is handled as development task. This is my way of defining the differences between a defect and an incident. I have found that by making this distinction I can design better workflows in Jira that make incidents more visible. I can also use this in Jira Service Desk and other systems and by separating the two types I am not limiting the different workflows and I do not have to bloat the workflow by combining the two into one. Do you agree with my definition?
  6. Some people say Defect and some say Incident. Both are correct, but what is the difference and why does it matter? In this article I will explain how I see the difference, why it matters and perhaps more importantly when it matters. When it comes to defects, then we have already defined that a defect is when the solution does not fit the requirement. We also defined what a defect is not, so we should be fine with just the term defect. Right? Well, there are actually a few reasons why we should actually have have two different definitions for a defect. The Legal Aspect One of the least understood aspect of defects is the fact that there is a point in the development process that change the way we manage defects. That point is when a solution is accepted, which occur during the acceptance phase before code is deployed and released in production. From a legal perspective this is when the standard agreement between the client and the provider is fulfilled. There might be additional services added beside the standard agreement that add another layer on top of the standard one, like a post go live support period or extended defect management after release. This point in the development is also where responsibilities sometimes shift from the development team to a maintenance team for example. The Complexity Aspect Another important aspect is the complexity aspect that comes into play as the deploy is released into a production system. Even if the pre-prod environment is identical to the production environment it is still withing the development teams responsibility. Once put into production this usually changes and the complexity with the full solution as well as the full network make it a much more costly affair to manage problems. When issues occur in the development teams environments it rarely involve other teams. Problem are managed within the team with the occasional support from surrounding system teams or network teams. Once you go to production however problems often become the affair of many teams. The Workflow Aspect How the team work with a defect is not the same for something found in a production environment, for obvious reasons. In a normal development workflow you can choose what code go to production, but for a defect found in production you do not have that choice. This is why you bypass the normal workflow and use hotfix, which is a fast track to correct problems in production environments. Two ways of working, two types of defects Based on the fact that we do have different processes for a defect found in production and for a defect found in the lower environments we should separate the issues themselves. This is not just to make it easier to identify in for example Jira, but also since there can be differences in who will manage the defect and the process to manage the defect itself. It also allow us to define the defects differently. Defects are problems that prevent acceptance. If there is a defect, then acceptance should not be given. It is a problem that only affect the legal aspects of an agreement. It can cause delays, which in turn can damage the company financially, but it will not affect the end user as it has never been released. By definition a defect is considered an internal problem and solving it involve only the development team within the standard way of workflow. It is simply development not yet complete. The severity of a defect determine when in time it should be fixed based on dependencies withing the project as well as surrounding systems. Defects are considered free since they are part of the development agreement. In Jira a defect is placed inside a development to block it from going into production. Incidents are problems that can damage the company. An incident found in production is available to end user and as such it can cause damage to the company. It can cause disruption of service, it can damage the brand perception or even cause direct impact on sales. Solving this problem often involve multiple teams and it require a separate workflow that disrupt the standard workflow. By definition this is an external problem and it can cause legal issues as it is found after acceptance has been given. The severity of the incident determine when in time it should be fixed based on the damage it causes. Incidents always comes with a cost, which usually is some form of support or maintenance agreement. In Jira an incident is a standalone issue that is handled as development task. This is my way of defining the differences between a defect and an incident. I have found that by making this distinction I can design better workflows in Jira that make incidents more visible. I can also use this in Jira Service Desk and other systems and by separating the two types I am not limiting the different workflows and I do not have to bloat the workflow by combining the two into one. Do you agree with my definition? View full blog article
  7. Learn how to write automated accessibility tests using Nightwatch.js and the Axe accessibility tool. This tutorial will cover how to write automated tests, based on WCAG, using these as accessibility testing tools for your website using browser automation provided by Nightwatch's chromedriver, or selenium driver if you prefer, by pairing Nightwatch with the nightwatch-axe-verbose custom commands.   This allows you to write assertions for web content accessibility guidelines and know what elements are failing accessibility rules for remediation.   For more information you can visit https://www.davidmello.com/accessibil... and for the source code used in this tutorial https://github.com/reallymello/nightw...
  8. For agile teams, all product release cycles typically follow the same route – Once the storyboarding is completed, backlog is set up in Jira, tasks are assigned to development after you work out the estimates. Then it is time to ship the application to an initial release. Agile teams across the world are familiar with Jira – the collaboration tool designed for issue and project tracking developed by Atlassian. While the basic use of Jira is to track issues, bugs etc. with your mobile and software apps, many teams have extended its use beyond just planning, managing and reporting. For example, some DevOps teams like using Jira for test case management. And with a little creativity, a little customization, it can absolutely be configured to support manual test case management. However, when it comes to supporting Test Automation in Jira, there is no direct way of doing that in Jira. The only way to incorporate or support Test Automation in Jira is by installing supporting apps from Marketplace in your Jira instance. Now there are two categories of apps that could help your agile teams achieve test automation in Jira. One is – Test Automation Apps. The problem with these apps is they only support automated test cases. Now to manage manual test cases, you will still have to rely on some other marketplace apps or do it in Jira as suggested earlier. The other option is to install – an app from the category Test Management Apps.   QMetry Test Management for Jira (QTM4J) offers complete test management capabilities to Agile and DevOps Teams inside Jira. QTM4J provides powerful test authoring capabilities for Manual Testing as well as provides seamless integration with Automation tools. QTM4J has integration capabilities with automation tools such as QAF/QAS that is QMetry’s Selenium based framework and IDE developed as part of contribution towards Open Source Community. It also allows integration with other automation tools such as HP UFT, Cucumber, Specflow, JUnit and TestNG. So how does this Test Automation work inside Jira? QMetry Test Management for Jira integrates with Automation Tools which then allows users to import automation test results into Jira. Now there are two different ways of integrating with the automation tools – Users can directly import their automation test result (JSON/XML/Zip) files using a REST API as soon as the automation test gets executed, which creates a new test run in Jira with all associated test cases and results as executed in the automation test. QMetry can easily integrate with other CI/CD tools. There are ready made plugin available for Maven, Jenkins and Bamboo for importing test results. So next question that arises is – How does Test case reusability work to avoid repeatability between manual and automated tests? This is how QTM4J ensures reusability – If Test case summary and Test step summary (for all steps) matches with the automated Test case, Test case key and version will be reused. If Test case summary matches and Test step summary do not match (for any of the steps) with the automated Test case, Test case key will be reused but new version will be created. If Test case summary does not match, new Test case will be created. Combining the power of Jira and automated testing can remarkably speed up your cycles, improve collaboration and execute metrics that help with project delivery and visibility. To see this in action, sign up for a free trial of QTM4J.
  9. Join core JUnit 5 committer Sam Brannen to gain insight on the latest new features in JUnit 5, as well as what’s on the horizon. In this presentation, we'll look at exciting new features that have been added in JUnit 5 over the past year, including parallel test execution, temporary directories, custom display name generators, method ordering, timeouts, the Test Kit, and powerful new extension APIs. If you haven't yet made the switch from JUnit 4 to JUnit 5, you'll definitely want to check out this presentation. In closing, Sam will also provide a few tips on how to use JUnit Jupiter to test Spring and Spring Boot apps. Speaker: Sam Brannen, Principal Software Engineer, Pivotal Slideshare: https://www.slideshare.net/SpringCent... Filmed at SpringOne Platform 2019
  10. Jira tool manager with the task of stabilizing the system and setting up work processes for all teams within H&M. Responsible for several projects including cloud initiatives and coordination with other systems such as ServiceNow. Heavily involved in designing the build processes (requirements, development, design, deploy and test) for the process office. Responsible for the design and implementation of SAFe in Jira and the build processes. Responsible for a small team of Atlassian experts. Supported 400+ teams with Jira questions and training of work processes.
  11. Margit Mattson är CEO för Claremont Quality services (CQS). Jag träffade Margit över en trevlig middag på Gute som senare övergick lång promenad runt Stockholm. Under våra 90+ minuter pratade vi om många saker och det som presenteras här är endast en liten smakbit på den intressanta och glada konversation som Margit bjöd på. Detta är en del av en intervjuserie som heter #jimisprofiler och Margit har självfallet granskat och godkänt att den information som följer. Margit, berätta lite om ditt företag och vad ni gör? Claremont Quality Services levererar Test as a Service (TaaS). Det är ett spännande område där det händer en hel del. Förutom Claremonts open source ramverk för automatiserade tester (TAF), kan CQS erbjuda i stort sett allt inom test som tjänst. Oavsett om du behöver hjälp att utvärdera ditt kvalitetsarbete, planering av arbetet med kvalitet, testledning, automatiserade tester, prestandatester eller någon som kan kliva in och leverera, så har CQS det du behöver. CQS överlappar en hel del med CQM och tillsammans bildar de affärsområdet Quality Solutions som kan hantera alla behov gällande test och kvalitet. På Claremont utbildas varje medarbetare och vi får lära oss om DISC som ett steg att förstå varandra och omvärlden lite bättre. Utifrån DISC, vilken är din disposition? Jag har SD, som både yttre och inre disposition. Det gör att jag ibland kan vara lite Jekyll och Mr. Hyde då jag är både tillbakadragen och timid, men samtidigt så visar jag vägen med hela handen när det gäller att leverera Vart är du född och uppväxt? Min familj arbetskraftsinvandrade från Finland och jag är född i Tullinge. Senare flyttade vi till Södertälje där jag är uppvuxen. Jag gick i skola i Södertälje och utbildade mig till Grundskolelärare i matte och NO. Efter 13 år så kände jag att det var dags för något nytt och jag skolade då om mig till projektledare. Så småningom var det test som blev mitt fokusområde och det känns otroligt givande att vara på Claremont efter en lång och krokig väg. Vad gör du när du inte jobbar? Jag tillbringar mycket tid i ridskolan där jag tränar och ibland tävlar i dressyr. Skidåkning, både utför och längd är också en passion. Jag älskar också golf, men om jag ska välja mellan golf och dressyr så vinner hästen alltid. Berätta något som ingen kanske vet om dig? Jag har tävlat i bowling och varit med i SM. Jag cyklar också en hel del, framförallt på landsväg och jag har tre cyklar för olika ändamål (Mountainbike, Landsväg och hybrid). Om du fick möjligheten att göra precis vad som helst, vad skulle det vara? Det skulle vara hästar för hela slanten. Vilken är den största utmaningen för dig som chef på Claremont? Den största utmaningen är att vara närvarande ledare, eftersom vi är utspridda som team. Test är hett eftertraktat så vi jobbar mycket mot kund, så det ibland lite svårt att hålla samma översikt över vem som behöver stöttning i teamet, ett skratt eller bara umgås en stund. Detta är lättare när vi sitter samlade då jag ser på kroppsspråk och höra på tonläget om det är någon som behöver mig. Om du får välja själv, vilken superhjälte skulle bäst representera dig? Modesty Blaise. Hon är en av de första riktigt starka kvinnliga karaktärerna och även om hon är tuff och bekämpar farliga brottslingar så använder hon och hennes kompanjon ytterst sällan dödligt våld. Istället använder hon list och sin extraordinära kunskap inom kampsport Välj en person som du känner som du skulle vilja ställa en fråga till. Vem skulle det vara och vilken skulle frågan vara? Vår nya styrelseordförande Olof Sand: Om 3 år, vilken skillnad ser du att Claremont har åstadkommit för våra kunder? Med det tackar jag Margit för en trevlig pratstund och hoppas på fler samtal i framtiden. Området Test är ett område som jag är mycket passionerad för så jag diskuterar det gärna och ofta. Vill du veta mer om någon eller vill du själv anmäla dig till den här serien, så skriv en kommentar så ska jag se vad jag kan göra. Vill du komma i kontakt med Margit så kan du kontakta henne via Linkedin eller Claremont's kontaktsidor.
×
×
  • Create New...