wiki-notes

Repository of QA wiki notes

Traditional Way

My own acquaintance with Test Management systems stemmed from experience of working with enterprizes who have money to buy licenses and time to project manage the QA projects/work/initiatives. Without doubt, this systems are independent softwares with good amount of workflow spread for different test activities. For eg: Requirement Creation, Test Design, Mapping of requirements, Test Execution and Defect reporting etc. So it has pretty effective management. THere are tools with good range of cost of options appropriate for medium to large corporations. Even introduction of Agile has been taken a good care of in these tools. Famous HPQC was renamed as ALM (Application Lifecycle Management) from version 11.0. These new version had capability to ingest Agile concepts like sprints etc. Similarly there are other test tools which dont have support like ALM but do have enough to get QA team going unless there is specific need for all features or may be the product involved is a real-time one which requires strict quality monitoring. In fact, there are project management, defect management tools which are now adding test management features. For eg: Jira has test creation capabilities with some plugins enabled while tools like VersionOne has features of creating tests for each story.

Custom Way

I had infact an opportunity to build a Test Management System for a company to replace HPQC in order to save costs. From that experience I gathered, that it wouldnt really take much to build dedicated test management systems for small to medium sized needs where QA would just add requirements, tests and mark execution records.

Neo Way

I am hoping to now create approach for much slimmer way of doing those basic things for “continuous” testing. Continuous testing as we know associates with Agile and DevOps. These processes are supplemented by test automation at various levels. However, Manual testing is bump to that “Continuous” keyword. So we kind of have to wait until everything is “automable”. However there is some scope of reducing time when we think of Manual test management workflows. Also in times of “collaboration and communication”, it is highly advisable to all teams(product, dev, support, business) know what QA teams is doing. In most of extreme agile teams, they wouldnt bother to go to explicit TMS to review or view test cases.

With advent of markdown format which is readable on most of version control systems(and that I am writing in), QA can take advantage of writing tests/scenarios in that format to start with. Those markdown files can lie as bunch in repository of respective applications. This way DEV and other teams which are usually referring to version control systems such GitHub or TFS can have unrestricted access to (manual or automated)tests being created for respective applications. A utility can be created for getting statistics of those files and tests contained within. This will take care of “Test Design” part of Test management approach. Other thing that would be required is creating “test execution records” without having to go through much workflow. This again can be achieved through utility which converts markdown to excel as done here Markdown to CSV and then marking execution statuses. There are other parts that remain like generating build-to-build statistics, showing them on git etc.

I am saying this as “DEV like” as you would you have noticed there is no reference of UI for writing test cases, creating test execution records. All is command-line through various utilities.