![\"\"\/](\"https:\/\/lh6.googleusercontent.com\/IaBbaK1yYb5exQo4UrsDN6llEWE_BlcLZhLJLGQGWzArSxvZdHSjcyUO_837g1t34wfjGRsH0DsIo65FQH82aYeue0QDOjO36QNmes82qDfYW99HDBHPnV9pcHrUE6_lzbhQlQQ=s0\")
<\/figure>\n\n\n\nIn my case, I chose Agile + Automation for a template, and I was ready to add tests or other information immediately. <\/p>\n\n\n\n
Customization<\/h2>\n\n\n\n
The customization options and flexibility in PractiTest are amazing. In my initial exploration, I started creating some placeholder test cases, but quickly got distracted with all the fine tuning and tweaks that are available. Because I could, I added the Angry Weasel logo to my dashboard, added a few test tasks, and I was in business.<\/p>\n\n\n\n As you can see, PractiTest offers a completely customizable task board you can use to track work in progress. Using the board isn\u2019t a requirement, but if you\u2019re using PractiTest to track scripted or exploratory test cases or charters, I think the ability to visualize work in progress is essential.<\/p>\n\n\n\n PractiTest is set up out of the box with three test types – Scripted<\/strong>, Exploratory<\/strong>, and Automated<\/strong> Test<\/strong>. It also has a Requirement<\/strong> type – which is nice to have as you can directly link Tests to Requirements and view the relationship in a Traceability tab, which is available both from the Requirement, and an individual test.<\/p>\n\n\n\n Of course, there\u2019s also an Issue type that can be used for bugs, suggestions, etc. as needed. It\u2019s also straightforward and easy to set up PractiTest to use with a wide variety of external Issue tracking tools. The list of connected tools is extensive (and unfortunately beyond the scope of this current round of kicking the tires of PractiTest).<\/p>\n\n\n\n You can choose to use the test types in PractiTest as you see fit – but I have some opinions and preferences (and experiences) with each of these test types that\u2019s probably worth diving into in this article.<\/p>\n\n\n\n I know a lot of teams that don\u2019t use Scripted tests (tests with pre-defined steps and outcomes) at all – and that\u2019s fine. On a lot of Agile teams, those testing the code, and those developing the code work extremely closely (or are the same person). In many of these cases, writing a bunch of test steps may not seem as efficient as exploratory testing. In fact, on most<\/em> of the products I\u2019ve worked with over the last ~6 years, I haven\u2019t used scripted tests. However, sometimes I\u2019ve been on teams where we\u2019ve found it necessary to get another team to help with testing (usually on different devices or environments that we didn\u2019t have on our local team. In these cases, sharing a set of scripted tests with those teams helped significantly. <\/p>\n\n\n\n I really like the way Exploratory Tests are set up in PractiTest. I\u2019ve used the concept of Test Charter and Guide Points (under various names) for my entire career, and think it\u2019s a great way to guide investigative testing of any product.<\/p>\n\n\n\n For me, I define the charter as \u201cthe thing I want to do with this exploratory session\u201d – and then I usually time box the effort. For a daily build of a simple website I may take just 30 minutes for exploratory testing. I use the Guide Points as reminders of things that I may want to poke at or investigate during my exploratory session. <\/p>\n\n\n\n It\u2019s worth mentioning that I\u2019ve found that scripted tests can easily and often become exploratory tests. Years ago, I worked on a product where a contract team ran a set of scripted tests on every build. After a short time, I found that the team was coloring outside the lines a bit while running the tests. They knew the product well enough that most times; they ended up exploratory testing, and marking off test steps as they ran across them. <\/p>\n\n\n\n I created a Test Charter and some Guide Points for every feature area of the product (taking some input from the existing Scripted Tests and previous Issues), and the testing quickly became both more efficient and more effective. <\/p>\n\n\n\n PractiTest handles automated tests in a few different ways. First, there\u2019s the FireCracker tool<\/a>, which just lets you take xml output from any test tool (or any tool for that matter) and import it as test results. The second method is xBot<\/a>. xBot is an agent that allows you to run a test on a remote machine via PractiTest. It\u2019s a simple, but effective way to run tests directly from the PractiTest UI. Finally, for ultimate flexibility, PractiTest has a REST API<\/a> that allows you to connect just about any automation framework. I was pleased to see a lot of examples of connecting a variety of tools to PractiTest. I played around with this feature quite a bit, and it was pretty straightforward to interact with test case details via curl in a terminal. It\u2019s worth noting that you can create new items from the REST API – so there\u2019s a great opportunity to create new Issues (bugs) directly from a wrapper around your automation and add stack traces, environment variables, etc. to make debugging test failures easier.<\/p>\n\n\n\n I think this area especially is an outstanding example of where the extensibility of PractiTest makes it a great tool. I love that it doesn\u2019t try to be too many things – but that it let\u2019s you make it work they way you want rather than changing your workflows to make it work as I\u2019ve had to do with many other tools in my career.<\/p>\n\n\n\n While I definitely put PractiTest through a decent amount of poking, I didn\u2019t dive into several of the features. Most notably missing from this review are the dashboard and reporting features, and the ability to connect to other Issue Tracking tools (Bugzilla, GitHub, Jira, and more). Like the rest of PractiTest, the dashboard and reporting features are highly customizable and extensible. There are a nice set of core features that don\u2019t try to do too much, and it\u2019s intuitive to use. <\/p>\n\n\n\n Overall, for me, the big win with PractiTest is the extensibility. I don\u2019t want tools to get in my way, and I don\u2019t want to change my workflows to make the tests work for me. I feel like PractiTest provides a great way to be the right tool for a lot of teams – and that\u2019s a huge achievement.<\/p>\n","protected":false},"excerpt":{"rendered":" The folks at PractiTest recently asked me to take their test case management tool for a spin. It\u2019s been a while since I\u2019ve used a tool like this, and after several hours of exploring and playing, I was reminded how valuable a flexible tool like PractiTest can be to assist and accelerate testing. I\u2019ll go…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[30,28,29],"class_list":["post-1967","post","type-post","status-publish","format-standard","hentry","category-allposts","tag-moderntesting","tag-practitest","tag-testmanagement"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/1967","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=1967"}],"version-history":[{"count":2,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/1967\/revisions"}],"predecessor-version":[{"id":1969,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/1967\/revisions\/1969"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=1967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=1967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=1967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"\/](\"https:\/\/lh4.googleusercontent.com\/bq_M86dE_WuJZsYB1tWXFaOywZ1RDZMM2Yg54Zfit2ZwwRmP5v0WJqUEk-9spLYpjjFAmqbMccqstJrC1NprLCwLMehll9PURwMCmoFJdVpVZXgBZXwG7DHcCgyRBlX8PvGIsTQ=s0\")
Item Types<\/h2>\n\n\n\n
![\"\"\/](\"https:\/\/lh4.googleusercontent.com\/kQtCurwphAsbaLSzsO0EN-D3aAvabQ-oPmK2XcvY1YcTIx31yuctoN592GoIvRHpEImvhDZLUGA8sZn1XMD5uzv9tfI3hY88v-Nt77RTOZ7wuBVIp2niqXFemOd2tcGQnsOZwMs=s0\")
Tests<\/h2>\n\n\n\n
Scripted Tests<\/h3>\n\n\n\n
Exploratory Tests<\/h3>\n\n\n\n
![\"\"\/](\"https:\/\/lh3.googleusercontent.com\/bsfPiPzRNNKG6e7dJ_XO8Qu-_lQIDv5xMto101YY1TBdOx3Pi61l3M5T7CjBcTiB2Tdq3xwLFjKYuAsBfD0OQ2yQ_clo4x44VqxiJ_TRl-KP5Jj1HqlQ8XvVJWMvsDnbpeD1qm0=s0\")
Automated Tests<\/h3>\n\n\n\n
Closing Thoughts<\/h2>\n\n\n\n