1

Is it generally accepted that it's ok in the Drupal community for QA testers to directly update and delete data in Drupal core tables via SQL? Or is it considered a bad practice? I'm talking about non-production environments--Production is definitely a no-no.

We are fortunate enough to have dedicated Quality Assurance engineers. I'm a developer and am very cautious about writing SQL update and delete statements on our Drupal tables (again, non-production). We usually script things in drush or use Drupal's API.

I think our QA engineers are great, but it seems like a very risky venture to directly update and delete data in core Drupal tables with SQL, even in non-Prod. I would think using tools such as Selenium or scripted solutions that use an API would be preferred, as long as they provide the same functionality.

Your input would be greatly appreciated. Any links with guidelines on this topic would be extremely helpful too.

Improve this question
5
  • 1
    It's very hard to answer this - if they're going to get it right, and not make mistakes, then yeah, let 'em at it. If not, then don't. If the risk is acceptable, do it, if it's not, don't. If your backup/recovery processes are solid enough, it should be fine. If they're not, it probably won't be fine. And so on... If you're interested in literal, to the letter, "best practice" only, then I think you've already answered your own question - they shouldn't be touching the database, only the API. And a non-developer shouldn't be going near an API. Or a database , for that matter
    – Clive ♦
    Dec 23, 2015 at 15:29
  • Clive, thanks for your response. You're right--it's very hard to answer this, and the answer could depend on a lot of factors. I'm trying to get specific feedback like "Yes, it's pretty common for QA to directly manipulate databases in the Drupal world and here's a reason why..." or "No, I've never heard of people allowing QA to do this in a Drupal environment." Thanks again.
    – Nes Fel
    Dec 23, 2015 at 16:27
  • No worries. I'm not aware of guidelines so I can only give you my personal experience/opinion, but I'd lean towards your own instincts and say I don't think it's a wise idea. Because of entities/fields/revisions it can be messy to deal with a Drupal database directly at the best of times. Things can often look like they work then an hour, a day, a week later, you realise you've missed something and some data's gone forever. Unless you're also QAing the SQL scripts themselves, doing it manually could actually make your QA process more of a headache, and worse, potentially inaccurate
    – Clive ♦
    Dec 23, 2015 at 18:04
  • In fact, if you want to update your question with a brief list of things that your team are responsible for QAing, and what they might want to run the SQL scripts for, you might get some good suggestions for more robust methods (e.g. Devel Generate for bulk creating dummy content)
    – Clive ♦
    Dec 23, 2015 at 18:09
  • Clive, really appreciate the additional input you provided. That's a great idea to provide specific examples. I realize now that my question is a bit too broad. I'll collect a list and post something more specific. The only example provided so far was switching user roles, which isn't super worrisome, but it wouldn't be limited to that.
    – Nes Fel
    Dec 23, 2015 at 18:43

1 Answer 1

Reset to default
1

If you directly update and delete data in Drupal tables via SQL, you don't allow Drupal core and third-party modules to detect such changes.

Instead, I suggest you have a look at some (common used) modules that may help updating/deleting such data, in "the Drupal way". Just to mention a few:

  • Flag - eg to "mark" nodes, users, etc for anything that's relevant for testing purposes.
  • Rules - eg to automagically make all sorts of things happen (eg after something like a node or user got flagged with the Flag module).
  • Views Bulk Operations (VBO) - to perform mass updates/deletes on a "list" (created with the Views module) of nodes, users, etc, whereas the actual operations to be performed can be "specified" with custom rules (created with Rules), or the other way around where you create such VBO-list and use it as input for creating lists and loops using Rules.

By using the "Drupal way", you also respect its permissions/roles architecture while performing testing (instead of getting around all that via direct updates/deletes). Wouldn't you rather want to discover security holes in testing areas?

Apart from that, there is also the Devel module to facilitate automatically generating nodes, comments, terms, users, and more (for testing purposes).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.