1

I found it's really hard to divide the task of developing a website to a team of people.

The problem is a website should have consistent looking and be integrated in users' view. The style and page template need to be shared by all parts. Most of the website is access restricted, the access control system is dependent of all modules. Some modules need data from other modules (you can never ask user the same question again). Although these modules may run independently. The test data have to be generated by other ones.

With the increase of code, the website becomes harder and harder to test. Although we are maintaining a script to automate the deployment. But if anything goes wrong, a developer cannot solve the problem by himself, for he is not familiar with others' work.

What makes things worse is the configuration. Server settings are highly machine dependent. Some functions need to schedule tasks, so there are some crontab configurations. Some modules need other daemons running in the backend. Some applications require URL rewriting. To test the website, we need to configure all dependencies of all modules on all machines.

Is there any suggestion about how to test a website?

  • 1
    I think you should clarify the types of tests: unit, integration, acceptance, etc. because dependencies can either be mocked or eliminated in unit tests. – JeffO Jan 10 '14 at 13:19
  • I see this as mostly a human problem, not a technical one. Management needs to put in place a foundation that will cause the people involved to work together effectively, e.g. team building, quality inter team communications infrastructure, group responsibilities and rewards, ... – Elliptical view Jan 11 '14 at 15:46
3

You have three separate, unrelated issues here, which both are opportunities to improve the management of your website team. In order of difficulty for implementation, you need (1) a test server, (2) an improved architecture for your site, and (3) some coding standards your team can be compelled to follow.

(1): Implement a Test Server

If your website is important enough to have more than a single programmer work on it, then it's important enough to create a dedicated test server. The server can be a virtual machine if appropriate, but it SHOULD NOT be administered by your programmers, and it SHOULD be as identical to your production environment as practicable while not being the same machine.

Your developers can program on their desktops or on a third "development" machine, but code that goes on the test server should be there only for testing, and should be in a state such that it can be copied entirely either to or from the production server without any changes beyond perhaps a process reboot.

(2) Improve your site's architecture

It sounds like you may have a serious lack of separation between design, code, and content. Ensuring that your various components all have the same look and feel is NOT the same job as writing sensitive data-handling components, and even if they are performed by the same team they should be written in entirely different work sessions and stored in entirely different files.

Even if that was a miscommunication, your team both thinking that they need to fix problems in a deployment and not being confident on how to make those fixes is a huge red flag that a re-architecture would do. As you make your changes, you can also implement better test practices, such as a full battery of unit, integration, and system tests that can be ran on the test server after each change is committed.

(3) Adopt some mandatory coding standards

While it's absurd to think that you could force everyone to write their code always the same, whomever owns the site should be able to insist that all future work adheres to at least a basic level of standardization and clarity, sufficient that the code will not have to be abandoned if any particular member of the team leaves.

Documentation and comments are a good start, while clean code would be better, and a process of continuous improvement and depersonalized code ownership would be best of all. But, even moreso than the previous, this is a management question and not a programmer question.


Oh, and just in case you're looking for the more concrete answer of "how do i test a website", the best answer is "automatically, by either adopting a framework like QUnit, buying some contractor's test software, or writing your own."

Ideally, your test mechanism would be something that is stored in the website code itself, and can be called even on the production server (when invoked locally).

0

just some thinking in case you can find something helpful.

"Server settings are highly machine dependent", "we need to configure all dependencies of all modules on all machines." maybe you can reduce this problem creating the work environments with vagrant provisioned by puppet or whatever.

The more decoupling is your code the easier is going to be the unit testing and mocking. So I just can recommend you to planning refactoring workflows to achieve a more decoupled code.

Regarding the functional testing I just can say you should choose a framework (Cucumber for Ruby, Behat for PHP, etc) I try to make the most of the provided API to fit your necessities.

-1

Regarding the functional testing, you can also have a look to Selenium, a web browser automation tool enabling you to create and run complex functional scenarios.

See http://docs.seleniumhq.org/

  • this does not answer the question asked – gnat Jan 10 '14 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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