{"id":4725,"date":"2016-03-19T16:16:02","date_gmt":"2016-03-19T16:16:02","guid":{"rendered":"https:\/\/www.process.st\/templates\/software-debugging-process\/"},"modified":"2024-02-28T16:41:44","modified_gmt":"2024-02-28T16:41:44","slug":"software-debugging-process","status":"publish","type":"post","link":"https:\/\/www.process.st\/templates\/software-debugging-process\/","title":{"rendered":"Software Debugging Process"},"content":{"rendered":"<section id=\"introduction\">\n<h2> Introduction <\/h2>\n<div class=\"image-content\">\n<figure>\n   <a href=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/tFXd-lpNxEMaC8rJHoREeQ.png\" alt=\"Introduction\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/tFXd-lpNxEMaC8rJHoREeQ.png\" \/> <\/a><br \/>\n  <\/figure>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>From being unable to login to an <a href=\"https:\/\/www.newscientist.com\/gallery\/software-bugs\/\" target=\"_blank\" rel=\"nofollow noopener\">entire rocket<\/a> going up in flames, software bugs can cause problems which nobody wants to deal with. When coupled with the fact the bugs will&nbsp;<em>always<\/em> be a problem, the entire software debugging process can seem daunting or even a little futile.<\/p>\n<p>&quot;<em>... mistakes are inevitable... good programmers make cheaper mistakes in order to avoid making more expensive ones<\/em>&quot; - <a href=\"http:\/\/www.yegor256.com\/2015\/06\/18\/good-programmers-bug-free.html\" target=\"_blank\" rel=\"nofollow noopener\">Yegor Bugayenko<\/a><\/p>\n<p>That's why we've come up with this software debugging process; big or small, use this process to solve your bugs step-by-step. From reproducing and breaking down the issue to analyzing, solving and publishing the fix, read on to go through every step you'll need to debug your software!<\/p>\n<p>Note that we have assumed you are working on a bug assigned within a sprint, ergo you should already have a standardized user story with some basic information to go off.<\/p>\n<p>Let's get bug swatting!<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"preparation\">\n<h2> Preparation: <\/h2>\n<\/section>\n<section id=\"take-a-look-at-the-initial-report\">\n<h2> Take a look at the initial report <\/h2>\n<div class=\"image-content\">\n<figure>\n   <a href=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/tWMyb99kfw7y9kQgy35GcQ.png\" alt=\"Take a look at the initial report\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/tWMyb99kfw7y9kQgy35GcQ.png\" \/> <\/a><br \/>\n  <\/figure>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>This goes without saying, but in order to fix a bug, you first need to have some clue of what the problem is.&nbsp;<\/p>\n<p>If set up correctly, use the<strong> form fields<\/strong> below to<strong> see the issue's ID, title and description instantly<\/strong>.<\/p>\n<\/p><\/div>\n<div class=\"text-field-content form-field-content\">\n<div class=\"form-group\">\n   <label> Title <\/label><br \/>\n   <input type=\"text\" placeholder=\"Something will be typed here...\" disabled=\"disabled\" class=\"form-control\" \/>\n  <\/div>\n<\/p><\/div>\n<div class=\"textarea-field-content form-field-content\">\n<div class=\"form-group\">\n   <label> Description <\/label><br \/>\n   <textarea placeholder=\"Something will be typed here...\" rows=\"3\" disabled=\"disabled\" class=\"form-control\"><\/textarea>\n  <\/div>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>Alternatively, go into your <strong>project management software<\/strong> and take a <strong>look at the user story for the bug report<\/strong>.<\/p>\n<p>Pay attention to any potentially relevant <strong>context<\/strong> or <strong>attachments<\/strong> (such as screenshots of the issue, or any detailed description of the topic).<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"log-in-to-your-code-repository\">\n<h2> Log in to your code repository <\/h2>\n<div class=\"text-content\">\n<p>Now that you have a rough idea of what is going wrong, you'll need to <strong>log<\/strong> <strong>in to your code repository<\/strong> in order to get a look at the offending code.<\/p>\n<p>Whether you're using <a href=\"https:\/\/github.com\/\" target=\"_blank\" rel=\"nofollow noopener\">GitHub<\/a>, <a href=\"https:\/\/bitbucket.org\/\" target=\"_blank\" rel=\"nofollow noopener\">Bitbucket<\/a> or <a href=\"http:\/\/projectlocker.com\/\" target=\"_blank\" rel=\"nofollow noopener\">ProjectLocker<\/a>, log into your account and<strong> navigate to the relevant project<\/strong>.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"navigate-to-your-bug-fix-fork\">\n<h2> Navigate to your bug fix fork <\/h2>\n<div class=\"text-content\">\n<p>In order to make any changes (or even effectively navigate to the relevant section) to your code, you're going to need to <strong>access<\/strong> a fork; usually, this is a<strong> specific fork<\/strong> which is <strong>used only for debugging purposes<\/strong>. Note that, depending on your repository, you may also need to download the fork onto your computer in order to make any changes.<\/p>\n<p>Although the navigation process will vary slightly depending on the repository of your choice, the term &quot;fork&quot; for a copy of the code is pretty universal, so you shouldn't have any issue finding the correct one.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"create-a-new-branch\">\n<h2> Create a new branch <\/h2>\n<div class=\"image-content\">\n<figure>\n   <a href=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/vnAnDg1wLMHpU_Labj1AFQ.png\" alt=\"Create a new branch\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/vnAnDg1wLMHpU_Labj1AFQ.png\" \/> <\/a><br \/>\n  <\/figure>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>The final stage of preparation is to<strong> create a branch<\/strong> of the fork to work on your specific bug.This helps when reviewing your bug fixes, as all fixes can be viewed as separate branches, rather than one huge clump.<\/p>\n<p>Again, the repo you are using will alter this step, but&nbsp;we'll use GitHub as a typical example. All you have to do is to navigate to your repo's<strong> branch selector menu<\/strong> and type in the <strong>name of your new branch<\/strong>. When the branch is not detected through a general search, you will be given the option of creating a new one.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"reproducing-the-issue\">\n<h2> Reproducing the Issue: <\/h2>\n<\/section>\n<section id=\"replicate-the-branchs-conditions\">\n<h2> Replicate the branch's conditions <\/h2>\n<div class=\"text-content\">\n<p>The first active step in&nbsp;debugging your work is <strong>reproducing the problem<\/strong>, as this will allow you to focus down on the exact piece of code which is causing the problem. To this end, you need to combine what you have seen from the bug report with your new branch.<\/p>\n<p>Essentially, take any<strong> conditions<\/strong> that were mentioned in the original bug report and <strong>apply them to the branch<\/strong>. This could be pretty much anything, so work with whatever information you have been given. For example, you could be entering conditions such as:<\/p>\n<ul>\n<li>A particular user attempting to log in<\/li>\n<li>Any detailed software configurations<\/li>\n<li>Widgets being used<\/li>\n<li>Any set action being carried out<\/li>\n<\/ul>\n<p>Obviously, there are hundreds and hundreds of potential conditions, but your user story should give you enough concise information that specifying these will not be an issue.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"reproduce-the-bug\">\n<h2> Reproduce the bug <\/h2>\n<div class=\"text-content\">\n<p>Now that you've entered the relevant variables, it's time to<strong> run your branch and reproduce the bug<\/strong> which has been reported. This will allow you to begin focusing down on the section of code which is causing the issue.<\/p>\n<p>Make sure that you<strong> note down your method in the form field below,&nbsp;<\/strong>which can be&nbsp;<strong>linked back to the original user story&nbsp;<\/strong>to automatically update it.<\/p>\n<\/p><\/div>\n<div class=\"textarea-field-content form-field-content\">\n<div class=\"form-group\">\n   <label> Bug Recreation Method <\/label><br \/>\n   <textarea placeholder=\"Something will be typed here...\" rows=\"3\" disabled=\"disabled\" class=\"form-control\"><\/textarea>\n  <\/div>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>Whilst this step is as easy as running your branch of code with the new conditions and checking for the presence of the bug, its <strong>success will entirely depend on<\/strong>&nbsp;<strong>the conditions of the previous step<\/strong> - or rather, their validity. During this step, it is also worth noting down any extra bugs you find in a new user story within your project management app.<\/p>\n<p>If the reported bug does not make an appearance, chances&nbsp;are that you need to go back in the software debugging process and alter the conditions of the branch.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"finding-the-bug\">\n<h2> Finding the Bug: <\/h2>\n<\/section>\n<section id=\"insert-initial-breakpoints\">\n<h2> Insert initial breakpoints <\/h2>\n<div class=\"image-content\">\n<figure>\n   <a href=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/myJU3p6R4saXnsRoVZ5HXw.png\" alt=\"Insert initial breakpoints\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/myJU3p6R4saXnsRoVZ5HXw.png\" \/> <\/a><br \/>\n  <\/figure>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>There's no sense in analyzing your entire code repository in order to find a single bug; the sheer number of variables would be unmanageable. Instead, you need to <strong>enter breakpoints<\/strong> into your branch so that you can pause and review manageable chunks of data.<\/p>\n<p>Once again, the method for entering these breakpoints varies, depending on the software and code structure you are using. To use <a href=\"https:\/\/developer.chrome.com\/devtools\" target=\"_blank\" rel=\"nofollow noopener\">Chrome Developer Tools<\/a> as an example, you can either <strong>click the number of the line of code<\/strong> where you wish the breakpoint to be, or you can type the <strong>debugger<\/strong> keyword into your code itself.<\/p>\n<p>The location of your breakpoints is pretty much up to you, and will vary greatly depending on the bug in question. If you are certain that a particular feature is causing the issue, a good practice would be to isolate that feature's code with breakpoints.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"analyze-your-code-with-a-debugger\">\n<h2> Analyze your code with a debugger <\/h2>\n<div class=\"text-content\">\n<p>You've reproduced your bug successfully and have breakpoints to split up your data into manageable chunks. Now it's time to break out the <strong>debugger<\/strong> itself!<\/p>\n<p><strong>Run through the code<\/strong> with your choice of debugger, <strong>examining the variables<\/strong> every step of the way. Line for line (yes, it's tedious, but it works) <strong>verify what the program is doing<\/strong> and flag any segments which are not playing along.<\/p>\n<p>There are <strong>several techniques<\/strong> which can make this analysis easier, such as:<\/p>\n<ul>\n<li><strong>Talking to a rubber duck<\/strong> (explaining your code out loud until you cannot explain what a line does; this will likely be a source of the bug)<\/li>\n<li><strong>Writing technical specifications<\/strong> (examining what&nbsp;<em>should<\/em> happen against what actually occurs)<\/li>\n<li><strong>Using test cases<\/strong> (running smaller segments of suspicious code with sets of test variables to check functionality)<\/li>\n<\/ul>\n<p>Remember to cordon off sections of your code with breakpoints as you go along; if you find that a <strong>section is working correctly<\/strong>,&nbsp;<strong>put a breakpoint<\/strong> to prevent yourself going over that same segment again.<\/p>\n<p>Keep going until you've found the <strong>precise location of the errant code<\/strong> which needs fixing!<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"deploying-your-fix\">\n<h2> Deploying Your Fix: <\/h2>\n<\/section>\n<section id=\"write-your-solution\">\n<h2> Write your solution <\/h2>\n<div class=\"text-content\">\n<p>Once you have the bug isolated, you can actually <strong>work on correcting it<\/strong>! Import your code branch into a <strong>text editor<\/strong> of your choice, then get to work on your solution.<\/p>\n<p>Remember to use the <strong>form field<\/strong> below to <strong>note your fix down<\/strong>!<\/p>\n<\/p><\/div>\n<div class=\"file-field-content form-field-content\">\n<div class=\"form-group\">\n   <label> Bug Fix <\/label> <\/p>\n<div class=\"file-container\">\n    <button type=\"button\" disabled=\"disabled\" class=\"btn btn-default\"> <i class=\"fa fa-upload btn-icon\"><\/i> File will be uploaded here <\/button>\n   <\/div>\n<\/p><\/div>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>Remember that <strong>any changes<\/strong> you make are not final; they still<strong> need to be checked<\/strong> and put through your software deployment method before going live. Nevertheless, be as thorough as humanly possible - any error you make here will only require your attention later, when the resulting bug from it is reported and slotted into the next sprint.<\/p>\n<p>Once you have <strong>completed<\/strong> your fix, note it in the<strong> form field<\/strong> below.<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"make-a-pull-request\">\n<h2> Make a pull request <\/h2>\n<div class=\"image-content\">\n<figure>\n   <a href=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/kztXeQHT8vPwUJlTJNFAQA.png\" alt=\"Make a pull request\" target=\"_blank\" rel=\"noopener\"> <img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.process.st\/templates\/wp-content\/uploads\/2024\/02\/kztXeQHT8vPwUJlTJNFAQA.png\" \/> <\/a><br \/>\n  <\/figure>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>Once you have identified the bug and drafted&nbsp;the most valid solution,&nbsp;the final step in your software debugging process is to <strong>deploy your fix<\/strong>. Remember to<strong> record the date<\/strong> of this action in the <strong>form field<\/strong> below.<\/p>\n<\/p><\/div>\n<div class=\"date-field-content form-field-content\">\n<div class=\"form-group\">\n   <label> Pull Request Date <\/label> <\/p>\n<div class=\"date-container\">\n    <button type=\"button\" disabled=\"disabled\" class=\"btn btn-default\"> <i class=\"fa fa-calendar btn-icon\"><\/i> Date will be set here <\/button>\n   <\/div>\n<\/p><\/div>\n<\/p><\/div>\n<div class=\"text-content\">\n<p>To this end, you need to <strong>save<\/strong> the newly corrected branch of code into the fork repo and <strong>submit a pull request<\/strong>. Note that this may not be the last you see of this bug, as if your code does not pass testing it will just be returned to your pile, so keep an eye out for that.<\/p>\n<p>Congratulations on completing the software debugging process! Give yourself a pat on the back (or a beer after work) and remember that every time you run this process it will go quicker. In no time at all you'll be flying through the steps, wondering why bugs are even still a problem!<\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"sources\">\n<h2> Sources: <\/h2>\n<div class=\"text-content\">\n<p><a href=\"https:\/\/www.newscientist.com\/\" target=\"_blank\" rel=\"nofollow noopener\">New Scientist<\/a> -&nbsp;<a href=\"https:\/\/www.newscientist.com\/gallery\/software-bugs\/\" target=\"_blank\" rel=\"nofollow noopener\">Bad bugs: The Worst Disasters Caused by Software Fails<\/a><\/p>\n<p><a href=\"https:\/\/twitter.com\/yegor256\" target=\"_blank\" rel=\"nofollow noopener\">Yegor Bugayenko<\/a> - <a href=\"http:\/\/www.yegor256.com\/2015\/06\/18\/good-programmers-bug-free.html\" target=\"_blank\" rel=\"nofollow noopener\">Good Programmers Write Bug-Free Code, Don't They?<\/a><\/p>\n<p><a href=\"https:\/\/twitter.com\/ericlippert\" target=\"_blank\" rel=\"nofollow noopener\">Eric Lippert<\/a> -&nbsp;<a href=\"http:\/\/ericlippert.com\/2014\/03\/05\/how-to-debug-small-programs\/\" rel=\"nofollow noopener\" target=\"_blank\">Fabulous Adventures in Coding<\/a><\/p>\n<p><a href=\"https:\/\/twitter.com\/stackexchange\" target=\"_blank\" rel=\"nofollow noopener\">Stack Exchange<\/a> -&nbsp;<a href=\"http:\/\/programmers.stackexchange.com\/questions\/10735\/how-to-most-effectively-debug-code\" rel=\"nofollow noopener\" target=\"_blank\">How to most effectively debug code? [Closed Thread]<\/a><\/p>\n<p>David LaVine on <a href=\"http:\/\/www.controleng.com\/\" target=\"_blank\" rel=\"nofollow noopener\">Control Engineering<\/a> -&nbsp;<a href=\"http:\/\/www.controleng.com\/single-article\/six-debugging-techniques-for-embedded-system-development\/237ff38eedf9d15f5fe23081e0ca4207.html\" rel=\"nofollow noopener\" target=\"_blank\">Six Debugging Techniques for Embedded System Development<\/a><\/p>\n<p><a href=\"https:\/\/twitter.com\/stackexchange\" target=\"_blank\" rel=\"nofollow noopener\">Stack Exchange<\/a>&nbsp;-&nbsp;<a href=\"http:\/\/programmers.stackexchange.com\/questions\/79068\/what-is-the-difference-between-debugging-and-testing\" rel=\"nofollow noopener\" target=\"_blank\">What is the Difference Between Debugging and Testing? [Thread]<\/a><\/p>\n<p><a href=\"http:\/\/www.drpaulcarter.com\/\" target=\"_blank\" rel=\"nofollow noopener\">Paul Carter<\/a>&nbsp;-&nbsp;<a href=\"http:\/\/www.drpaulcarter.com\/cs\/debug.php#4\" rel=\"nofollow noopener\" target=\"_blank\">How to Debug Programs<\/a><\/p>\n<p><a href=\"https:\/\/www.concise-courses.com\/security\/author\/concise-team\/\" target=\"_blank\" rel=\"nofollow noopener\">Henry Dalziel<\/a> -&nbsp;<a href=\"https:\/\/www.concise-courses.com\/security\/top-5-hacking-tools-debuggers\/\" rel=\"nofollow noopener\" target=\"_blank\">Top #5 Hacking Tools: Debuggers<\/a><\/p>\n<p><a href=\"https:\/\/help.github.com\/\" target=\"_blank\" rel=\"nofollow noopener\">GitHub<\/a> -&nbsp;<a href=\"https:\/\/help.github.com\/articles\/creating-and-deleting-branches-within-your-repository\/\" rel=\"nofollow noopener\" target=\"_blank\">Creating and Deleting Branches Within Your Repository<\/a><\/p>\n<p><a href=\"https:\/\/msdn.microsoft.com\/en-gb\/default.aspx\" target=\"_blank\" rel=\"nofollow noopener\">Microsoft Developer Network<\/a> -&nbsp;<a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/y740d9d3.aspx\" rel=\"nofollow noopener\" target=\"_blank\">Navigating Through Code with the Debugger<\/a><\/p>\n<\/p><\/div>\n<\/section>\n<section id=\"relevant-checklists\">\n<h2> Relevant Checklists: <\/h2>\n<div class=\"text-content\">\n<p><a href=\"https:\/\/www.process.st\/templates\/git-workflow\/\" target=\"_blank\" rel=\"nofollow noopener\">Git Workflow<\/a><\/p>\n<p><a href=\"https:\/\/www.process.st\/templates\/user-story-template\/\" target=\"_blank\" rel=\"nofollow noopener\">User Story Template<\/a><\/p>\n<p><a href=\"https:\/\/www.process.st\/templates\/sprint-planning\/\" target=\"_blank\" rel=\"nofollow noopener\">Sprint Planning<\/a><\/p>\n<p><a href=\"https:\/\/www.process.st\/templates\/scrum-project-management\/\" target=\"_blank\" rel=\"nofollow noopener\">Scrum Project Management<\/a><\/p>\n<p><a href=\"https:\/\/www.process.st\/templates\/software-deployment\/\" target=\"_blank\" rel=\"nofollow noopener\">Software Deployment<\/a><\/p>\n<p><a href=\"https:\/\/www.process.st\/templates\/software-testing-tutorial\/\" target=\"_blank\" rel=\"nofollow noopener\">Software Testing Tutorial<\/a><\/p>\n<\/p><\/div>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Introduction From being unable to login to an entire rocket going up in flames, software bugs can cause problems which nobody wants to deal with. When coupled with the fact the bugs will&nbsp;always be a problem, the entire software debugging process can seem daunting or even a little futile. &quot;... mistakes are inevitable... good programmers [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":4726,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"ep_exclude_from_search":false,"cover_icon_emoji":"","cover_icon_url":"","tasks_count":"17","template_description":"Run this checklist every time you need to correct a known bug or error","template_id":"n6fzbCZal4pMPcaNiLlIiw","task_0":"Introduction","task_slug_0":"introduction","task_1":"Preparation:","task_slug_1":"preparation","task_2":"Take a look at the initial report","task_slug_2":"take-a-look-at-the-initial-report","task_3":"Log in to your code repository","task_slug_3":"log-in-to-your-code-repository","task_4":"Navigate to your bug fix fork","task_slug_4":"navigate-to-your-bug-fix-fork","task_5":"Create a new branch","task_slug_5":"create-a-new-branch","task_6":"Reproducing the Issue:","task_slug_6":"reproducing-the-issue","task_7":"Replicate the branch's conditions","task_slug_7":"replicate-the-branchs-conditions","task_8":"Reproduce the bug","task_slug_8":"reproduce-the-bug","task_9":"Finding the Bug:","task_slug_9":"finding-the-bug","task_10":"Insert initial breakpoints","task_slug_10":"insert-initial-breakpoints","task_11":"Analyze your code with a debugger","task_slug_11":"analyze-your-code-with-a-debugger","task_12":"Deploying Your Fix:","task_slug_12":"deploying-your-fix","task_13":"Write your solution","task_slug_13":"write-your-solution","task_14":"Make a pull request","task_slug_14":"make-a-pull-request","task_15":"Sources:","task_slug_15":"sources","task_16":"Relevant Checklists:","task_slug_16":"relevant-checklists","task_17":"","task_slug_17":"","task_18":"","task_slug_18":"","task_19":"","task_slug_19":"","task_20":"","task_slug_20":"","task_21":"","task_slug_21":"","task_22":"","task_slug_22":"","task_23":"","task_slug_23":"","task_24":"","task_slug_24":"","task_25":"","task_slug_25":"","task_26":"","task_slug_26":"","task_27":"","task_slug_27":"","task_28":"","task_slug_28":"","task_29":"","task_slug_29":"","task_30":"","task_slug_30":"","task_31":"","task_slug_31":"","task_32":"","task_slug_32":"","task_33":"","task_slug_33":"","task_34":"","task_slug_34":"","task_35":"","task_slug_35":"","task_36":"","task_slug_36":"","task_37":"","task_slug_37":"","task_38":"","task_slug_38":"","task_39":"","task_slug_39":"","task_40":"","task_slug_40":"","task_41":"","task_slug_41":"","task_42":"","task_slug_42":"","task_43":"","task_slug_43":"","task_44":"","task_slug_44":"","task_45":"","task_slug_45":"","task_46":"","task_slug_46":"","task_47":"","task_slug_47":"","task_48":"","task_slug_48":"","task_49":"","task_slug_49":"","task_50":"","task_slug_50":"","task_51":"","task_slug_51":"","task_52":"","task_slug_52":"","task_53":"","task_slug_53":"","task_54":"","task_slug_54":"","task_55":"","task_slug_55":"","task_56":"","task_slug_56":"","task_57":"","task_slug_57":"","task_58":"","task_slug_58":"","task_59":"","task_slug_59":"","task_60":"","task_slug_60":"","task_61":"","task_slug_61":"","task_62":"","task_slug_62":"","task_63":"","task_slug_63":"","task_64":"","task_slug_64":"","task_65":"","task_slug_65":"","task_66":"","task_slug_66":"","task_67":"","task_slug_67":"","task_68":"","task_slug_68":"","task_69":"","task_slug_69":"","task_70":"","task_slug_70":"","task_71":"","task_slug_71":"","task_72":"","task_slug_72":"","task_73":"","task_slug_73":"","task_74":"","task_slug_74":"","task_75":"","task_slug_75":"","task_76":"","task_slug_76":"","task_77":"","task_slug_77":"","task_78":"","task_slug_78":"","task_79":"","task_slug_79":"","task_80":"","task_slug_80":"","task_81":"","task_slug_81":"","task_82":"","task_slug_82":"","task_83":"","task_slug_83":"","task_84":"","task_slug_84":"","task_85":"","task_slug_85":"","task_86":"","task_slug_86":"","task_87":"","task_slug_87":"","task_88":"","task_slug_88":"","task_89":"","task_slug_89":"","task_90":"","task_slug_90":"","task_91":"","task_slug_91":"","task_92":"","task_slug_92":"","task_93":"","task_slug_93":"","task_94":"","task_slug_94":"","task_95":"","task_slug_95":"","task_96":"","task_slug_96":"","task_97":"","task_slug_97":"","task_98":"","task_slug_98":"","task_99":"","task_slug_99":"","footnotes":""},"categories":[5,7,16,31],"tags":[],"class_list":["post-4725","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-featured","category-miscellaneous","category-quality-assurance","category-software"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/posts\/4725","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/comments?post=4725"}],"version-history":[{"count":0,"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/posts\/4725\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/media\/4726"}],"wp:attachment":[{"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/media?parent=4725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/categories?post=4725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.process.st\/templates\/wp-json\/wp\/v2\/tags?post=4725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}