This is a thinly veiled cry for help....My background is in testing for the financial service industries (all the Is dotted - all the Ts crossed). I started testing about 17 years ago by typing the word 'junior' into Jobserve during a lunchbreak in a particularly unedifying IT sales job. It was the height of Y2K panic and I was rung directly by a programme test manager at a bank who hired me on the spot after a 5 minute chat - alas with all those now making a living by certifying what it means to be a tester things are not so simple for new starters in our profession.....

All was waterfall, sometimes it worked, sometimes it didn't, we had piles of excel spreadsheets which represented our test cases but which were probably just more of a fire risk and no
longer bore much resemblance to the application under test! There were rumours of automation but there were also rumours of hoverboards!

And so to today - those of us that work in industries which have stacks of legacy applications  'supported' by piles of manual tests (either as raw excel sheets or piled up in any number of test management applications (new like HP-ALM or old like Empirix or T-Plan), early attempts at UI only automation through some QTP esque tool and some shiny new stuff to support our scrum
teams (SOAP UI / POstman or Selenium with JUnit assertions all hooked up to Jenkins)

I'm wondering how other people have approached tracking test executions / bugs raised against such a mixed bag of tests. I want to have my eye on the future of work in my industry (which looks to me like using dev type skills to code repetitive tests as part of the development effort where those tests are specified by QAs who are using their test / domain knowledge to either define tests for automation or engaging in high value exploratory testing which may well involve tools but probably fall short of dev level coding)

A test execution represents work to be done by the team, as does a bug fix regardless of which test from the grab bag of old / new / automated / manual tests discovered it. Given that we're all 'Agiled' up I want that bug on a nice shiny sprint management tool (something like JIRA or VersionOne) but I want the minimum amount of rekeying caused by running a test in application A and raising a defect in appliation B! Oh, I also want to be able to record new manual tests in the same place as the bugs (some tests will live and die as exploratory tests on the sprint but some might have a longer lifespan and need to be perpetuated (especially where we're talking about tests across multiple integrated applications which are just more convenient to run manually)

I'll go first and hopefully someone will tell me how I could have done it better.

1) I migrated those tests which I believed had value from the legacy test management systems into HP-ALM. Legacy manual regression packs are run from here. (Any defects raised are raised
in VersionOne (like JIRA) and then manually referenced back to the test in HP-ALM).
2) I archived the DBs from the legacy test management applications just in case.....
3) The key excel tests were imported into HP-ALM
4) I got a SaaS instance of VersionOne which we use for bug tracking, sprint management, defining in sprint tests (manual and automated)
5) New manual tests for in sprint backlog items are written into and executed from VersionOne (but it doesn't have good long term test management capability - or at least the level I had
5) I thought about integrating VersionOne and HP-ALM but didn't because I thought it was going to generate too much chaff and be more hassle than it was worth.
6) Any VersionOne manual tests which we felt were worth perpetuating as part of a regression suite were imported into HP-ALM (really didn't like this bit!)
7) The old UI tests - I binned them. They only worked under a full moon after a good dose of peyote anyway!

I'm seeking an elegant solution to streamlining all the above - preferably open source but certainly not £1000 a license which is what HP-ALM was costing me. In short I want it all and I
want it now.

How would you guys do it?


Views: 340

Reply to This

Replies to This Discussion

Hi Rob.

I won't lie... I am hesitant to just start spewing ideas and thoughts here. I would however be interested in having a longer discussion about your company, some shared visions that exist there, and the biggest business challenges that you face as an organization. (Note: I am not speaking about testing here but rather the business and the market)

Do you feel comfortable maybe joining in with one of the slack groups that exists (MinistryofTesting.slack.com or Testers.io) to maybe have a bit more interactive discussion on this topic? We can report back here what we uncover and discuss.

Hi Martin.

I don't really know what happens at the slack groups. I've sent you a 'friend' request. If you respond to that I'll send you my no. and we can have a chat.



Thanks Rosie and Melissa. The article was really interesting and thought provoking. It reinforced my belief that out there in the world of large organisations there are various degress of chaos when it comes to managing our QA process (and like Melissa I take QA to have remit beyond the execution of tests). Once you move into a site that has had several different people (and at times no-one) responsible for the QA strategy you will inerit various levels of debt and silo-ism. With each of the latest incumbents keen to re-tool and move on without dealing with the pain of consolidation you can eventually find that providing the level of surety your client requires can be very challenging. The debt is insidious and one must be ruthless in trying to root it out (although as Melissa says - sometimes once you've made your case you have to be prepared for a 'no' - then you have to come at it another way!) 



© 2017   Created by Rosie Sherry.   Powered by

Badges  |  Report an Issue  |  Terms of Service