Quality Assurance

Guys, I am testing a drupal based project which will also involve quitesome migration activity in it. There will be taxonomies, nodes migrated from the existing site to the newly built drupal.
Can you please guide on how do I approach migration testing for taxonomies, customer records and nodes.

Hi Folks, I'm working in a module to run Unit Tests in Drupal with PHPUnit.

Actually the project is in a Sandbox state and is current development, but I wanna receive some feedback, opinion, suggestions, critics, features request, etc.

If anyone is interested in more data please put in contact with me.

http://drupal.org/sandbox/casivaagustin/1678226

Thanks and Regards

I make checklist, but i don't confident this list is right,

Drupal QA
Cheсklist
Functional
Security
Load & Performance
Localization
Usability

1.Functional
check functional on server phpmail, and other functions and apps for server
check watchdog
check version module drupal.org on site.
test developer modules (write test by simple test).
Automated Functional Testing Selenium , Windmill etc

2.Security
check configure on server (rewrite for module, files private etc), security file permission
check security review, (drupal module)
delete files in "/"

Hi there, I'm using Windows 7, IIS, PHP 5.3.10 nts running with FastCGI, SQL Server 2008 R2 with PDO 2.0 drivers for windows to run Drupal.

I'm suffering a very slow behavior running the Drupal Tests, never ends to run the tests, the others parts of the site works fine.

Any thought about what may is happening ?

We are currently seeking students interested in learning about our AWS testing implementations. The primary objective is to create a curriculum that will help educate others understand the methods utilized by the Drupal infrastructure to support it's automated testing in the Amazon cloud. This is a prime opportunity for you to become involved in Drupal and help create positive learning materials to help others understand the benefits of Amazon cloud services as they apply to Drupal.

Why should you read this article?

• Developer, Team Leader, Admin:
• You will find out how to use build script that will save your time, spend on configuration of your project on dev, test, stage and production servers, on local computers of managers and testers.
• Build script will allow you to make CI system and get all profits it gaves you.
• Manager:
• You have a lot of project in same time, and want to install in on local comp easily.
• You will get standart way to install projects on some machine in one click. To install new project you have to run $ant in console. Do this on local machine.
• You can demo machine with Husdon and build script. It will allow you allways have actual version of project to test and to show to client.
• Tester, QA manager:
• You have a lot of project in same time, and want to install in on local comp easily.
• You will get standart way to install projects on some machine in one click. To install new project you have to run $ant in console. Do this on local machine.
• You can make CI, add there tests and have regression testing easily.

Project page

ci-drupal

Motivation:
I'm going to grow quality of products we get in company I working in.
I'm going to make ability to show bugs free product when client what. (functionality that marked "done" realy 100% done)
I'm going to make code clear and developement process managing.
I'm going to make regressive testing cheap.
I'm going to remove trivial round things from my live.

CI can help us.

I just released an install profile for D6 core that sets up a test site for trying out all the combinations of CCK date field configurations: CCK Date Testsite. I've discovered various bugs in Signup's handling of CCK date fields (and have been fleshing out bugs and limitations in DateAPI itself with KarenS's help). I was spending a lot of time just configuring a reasonable test site to try different combinations of CCK date field types (Date, Datestamp, vs. Datetime) and timezone handling (there are 5 different ways date fields can handle timezones). So, I quickly decided the time spent automating the test site would easily save me time in the long run. And, I hope this profile will be useful to other folks working with DateAPI and CCK date fields.

Here is an effort at documenting Drupal testing patterns from what's currently used in core tests. The objective is to promote reusability of standardized patterns throughout core and contributed tests.

// Catch - this looks good, but I think we should completely ignore stuff like getContent() which is used once per year and just focus one what 70% of basic tests will use - the API docs etc. are there, and linkable at the end, for everything else.

It stands to reason that the tests in simpletest/tests will be the ones that people will use to base their own tests. These tests were written by at least 5-6 different people, and it shows. As a result, it's really confusing for a new developer to get a sense of what your own module's SimpleTest integration ought to look like.

This group will soon be merged into the http://groups.drupal.org/testing-qa group. That group used to be the unit-testing group but was expanded to include QA in general making this group less improtant. So...

If you haven't already, subscribe to http://groups.drupal.org/testing-qa

Yay for the removal and abolishment of redundancy and repetition! Yay for Webchick and Angela Byron!

If you're looking for current status, look at the most recent comment

Since we've still got core test failures, and no automated patch testing, I thought it'd be worth doing a snapshot of tests that pass week by week (or more frequently if there's lots of commits). This allows us to keep a historical overview of where bugs have been introduced into either core code, simpletest.module or tests themselves. It should also hopefully help to reduce duplicate issues about broken tests (since a test failure can be down to any one of those conditions).

<p>By: Robin Monks</p> 
<h1>Introduction</h1> 
<p>Drupal is community. It&#8217;s a community of visionaries that make Drupal what it is, we all want to see Drupal be more powerful, more flexible, and just plain better than the competition!</p>

Hold on, hear me out :o) We're a really focused and strong (and almost too commercial) community, and we really have put our focus on features and output, and we've lacked a lot when it's come to making it all work correctly in every possible case.

That's where quality testing comes in. I've been thinking about Drupal's quality assurance process for a couple years now, but in the last few months it's really come to a head for me. My personal "dam-breaking" moment came when the Batch API in Drupal 6 prevented install, and other tasks depending on the API from running automatically, or in text based browsers, or in browsers were people have been privacy conscious and disabled JS and Meta refresh tags.

Without proper quality trails this will continue to happen. And here's another point I'd like to make:

Continue reading and comment at DrupalFiles >

Background and Purpose
After the SimpleTest session Wednesday morning I talked with sethcohn about some possible solutions to some of the issues that are being faced with full scale implementation of the unit test coverage. Some of the ideas are specific to the SimpleTest framework, but much could be applied to other testing frameworks. According to chx it sounds like the SimpleTest framework is going to be used which makes this information especially relevent.

To start off the biggest unknown currently is how to go about implementing "function unit testing" (which I beleive is the term). In other words calling an individual function with different arguements and checking the results against the know correct output. Until now this has been virtually untested and, to my knowledge, not really thought about at all. Instead "functional" testing has been worked on (as I was apart of).

We received, by show of hands, a considerable number of people who claim to be interested in contributing to the testing challenge, as introduced by Dries in his keynote. If anywhere near the number of people that raised their hands contribute, it could create a very chaotic situation and put a lot of pressure on the SimpleTest maintainer(s). In an attempt to address this I have compiled some ideas and thoughts.

So I am writing a new CCK field and because I practice test driven development I find myself testing that I have implemented the CCK api hooks correctly. This basically means testing against the interface. Usually in a pure OO class orientated world for unit testing we would use a mock library (e.g.

Hello, since the QA BOF at DrupalCon Barcelona we have been developing an automated patch and unit testing system for Drupal core. We aren't quite ready to launch it live, but wanted to give QA enthusiasts an early look at what we are doing. Please review http://testing.drupal.org and file issues.

Hi everyone. I've written an article introducing unit testing and the Simpletest module on Lullabot.com. Hope you enjoy it!

There will be a discussion about Drupal testing and how to make it happen at Drupalcon Barcelona BOF room 1.
Sorry for such a short notice.