The target date is almost always important and firm. In managing website design and development projects for over half of my career, I have become very familiar with timelines that clients desire, especially tight timelines. As an agency, we’re always doing our best to hit and exceed client goals, but there are times when it’s a bad idea to rush your website project.

A website design and development project typically takes 12 weeks (or more) from initiation to completion. There are various phases throughout a project life cycle that are critical in ensuring a performant and secure website that delivers what the client is expecting. When you rush a website project to hit a particular goal date, you risk a lot.

Discovery is so important.

Rushing a website project typically means starting the development phase ASAP. This is a huge mistake.

The discovery phase of a project provides time for the Engineering Team to explore requirements with the client, research and plan. Planning is crucial to a successful project. We typically dedicate one to two weeks for the discovery phase a project.

The first week involves discovery calls with the client to gather information and requirements, as well as reviewing the scope and researching. The second week involves defining a development path, planning tasks and outlining a project plan for the client to review. Without a solid plan, you risk issues with development, confusion around client expectations, and ultimately not hitting the rushed timeline. Take time for discovery and planning, even when there is a hard deliverable date.

Processes (like code reviews) are in place for a reason.

Tight timelines on website projects usually force Project Managers and Engineers to look at the project life cycle, processes, etc., and see where they can cut corners in order to hit a date. Again, this is a huge mistake. Would you purchase a house that was built with steps skipped and corners cut? Of course, you would not. Why would you do that with your website?

The project life cycle is what it is. You have to plan, build, review the quality and prep in order to be successful with a website project. Similarly, the development phase standard processes are in place for a reason, and chances are they are well-thought through to make certain that the product produced for the client is successful. Cutting corners, like skipping code reviews, is not an option.

For example, we ensure every of line of code written at WebDevStudios follows the WordPress coding standards as well as our own internal standards, and we wouldn’t want our name on a product that wasn’t superb. We have a code review process in place that allows a Lead Engineer time to review the code and test features.

Every project timeline that we set, or agree to, guarantees that we allow time for this step. It’s important to verify the development work being done meets standards. Processes are meant to be followed even with tight timelines, and if there isn’t time to do things like plan or review code, then the timeline should shift to account for these key steps.

Quality assurance and testing cannot be eliminated in order to hit a target launch date.

It may sound crazy, but I have managed a few projects where the client wanted to wave the quality assurance and user experience testing in order to get a site launched for an important target date. If at all possible, please avoid this.

QA and UAT are extremely important. The QA phase gives the Engineering Team an opportunity to discover any design issues and development errors, while cross browser testing on a variety of devices. Additionally, it’s important to take time to run performance testing on the clients hosting environment before deploying to production. Without these quality assurance tests, you risk running into bugs post-production that can be costly.

We understand that project timelines are important. Consider the target date no different than a goal. When discussing the goals and target dates, be flexible. The Project Manager will always provide the best project timeline that works toward the goal, and if it doesn’t quite hit it that target date, they will have a valid reason why. Avoid rushing your next website project if possible, and I assure you, it will be more successful!

The post Why It’s a Bad Idea to Rush Your Website Project appeared first on WebDevStudios.

Today, I’m going to walk through getting started with Cypress.io—a JavaScript-based E2E platform that’s easy to get up and running and is powerful in numerous ways that could make you rethink testing.

What Exactly is “End-to-End Testing?”

End-to-end testing means testing your application in a way that each component, from start to finish, is tested to do what it’s supposed to do. As an example, imagine a website that has a “Contact Us” form. Testing this would mean filling out the form, clicking the submit button, and expecting to see a result afterwards of something along the lines of “Thank you for contacting us.”

This is a simple example; other examples include testing a Single Page Application, or a complex search with filtering and sorting. These kinds of tests aren’t hard for an individual to do, certainly, but as people, we’re prone to mistakes. Maybe you forget to see what happens if a checkbox is toggled on or off, or you don’t remember to try filtering a list after sorting to see if the sorted state remains after filtering.

With a testing suite, you can write tests that are both descriptive and repeatable. This helps us remember what we’re testing and ensures that with every iteration of a site or application, we can know what tests to run. Cypress also provides the ability to “step through” your tests after they complete, allowing you to see the application’s state at any given point as it was when the test was running.

The above GIF shows the Cypress sample test spec called “actions.spec.js.” You can see that Cypress opens its own browser, runs your tests, and allows you to jump to any point in the test history and see the application state as it was right then. Awesome, right?

Getting Started

You can find out detailed instructions for getting started with Cypress on their Installing Cypress page. For the purposes of this post, I’m not going to go into great detail, but I will walk through the simplest installation method and one most people are likely familiar with: the Node Package Manager. Before going any further, it’s important to note the system requirements for Cypress as of the time of this writing:

• Mac OS 10.9+ (Mavericks+), only 64bit binaries are provided for macOS
• Linux Ubuntu 12.04+, Fedora 21, Debian 8, 64-bit binaries
• Windows 7+, only 32bit binaries are provided for Windows

Now, fire up your terminal and go into your project’s root folder. Typically, this is where you’re already using node (if you use it). If you put your node modules elsewhere, just change to the proper location. Next, you’ll use the following command to start the installation process:

npm install cypress --save-dev

You may get a brief prompt from Cypress, but otherwise the package should install and plop you back in the terminal. Next, let’s fire Cypress up with the following:

$(npm bin)/cypress open

Firstly, “$(npm bin)” will cause npm to echo the location of the current directory’s binary folder for Node. Secondly, we take that output and concatenate it with the “cypress open” command. On my computer, this expands to “/Users/phatsk/src/WDS/local/playground/app/public/wp-content/node_modules/.bin/cypress open.” You should now see the Cypress screen:

Running Tests

Now that you have Cypress installed and running, you can peruse the samples provided in the “examples” folder. Try clicking one to open a Chrome window that will run the test and give you feedback to each test step. Here you can also click around, expanding tests and using Cypress’s “rewind” feature to see the previous state of the application it’s testing. In this case, the example tests all run against Cypress’s own documentation.

Writing Tests

This is where we start to have fun! Writing tests in Cypress is pretty easy. You just create a JavaScript file in the “cypress/integration/” folder, save it, and it should appear in the main Cypress window after a moment. For this post, I’m going to create a file called “cypress/integration/blog.js” and I’ll add the following content:

describe( 'Testing WebDevStudios.com', function() {
  it( 'Visits the Contact Page', function() {
    cy.visit( 'https://webdevstudios.com' );
    cy.contains( 'Contact Us' ).click();
    cy.url().should( 'include', '/contact' );
  } );
} );

The above script is fairly basic, and a good place to start. Let’s take a look at it, line-by-line:

describe( 'Testing WebDevStudios.com', function() {

This line simply defines our test suite. Here you would give your set of tests a descriptive name.

  it( 'Visits the Contact Page', function() {

Cypress tests are written in a way that kind of makes sense when you read them out loud. For instance, the start of this particular test in our suite describes what we want the test to do—“it Visits the Contact Page.” This line also opens another new function, which will contain our actual test code.

    cy.visit( 'https://webdevstudios.com' );

The “cy.visit” method visits a URL. This is a good time to have a side conversation about testing applications: you should only test applications you own.

The Cypress documentation goes into more detail in “Writing Your First Test.” Generally speaking, you won’t be doing much good if you’re trying to test a website or application that you don’t control, and if you’re looking for something to do automated tasks to test for things like load-balancing, there are much better tools than Cypress.

    cy.contains( 'Contact Us' ).click();

The “cy.contains” looks for an element with the text passed to the “contains” method inside of the elements you are selecting against. Since we aren’t chaining the contains command to any selector, it will return the first element on our page that contains the text “Contact Us.” Once we have that element, we want Cypress to “click” the element.

    cy.url().should( 'include', '/contact' );

Finally, we want to ensure that what we clicked took us to the proper place. For that, we assert that the current URL (via “cy.url()”) should include the text “/contact.” The “should()” method is an assertion, and if it passes or fails will be denoted in the Cypress log window.

You can see that Cypress has some pretty nifty features. It has methods for traversing the DOM, finding particular nodes based on text or selectors, and even is aware of when pages are loading so that your tests don’t run too early.

Where to Go Next?

Now that you have a basic idea of how Cypress works, you can start exploring their documentation and hopefully use Cypress to help you better test your applications. I know I’m going to be using it in my own work to help test the applications we create for our clients.

The post Introduction to End-to-End Testing with Cypress.io appeared first on WebDevStudios.

QA and UAT are review processes that are done during a web development project to ensure design and functionality requirements are met prior to a production release.

When you spend weeks, or even months, on a project only to wind up with a handful of QA issues (that you should have caught the first time around), it is easy to feel discouraged. You can receive QA feedback for scenarios you did not even think about the first time around. The person performing QA isn’t intending to discourage the developers. QA and UAT are intended to find the obvious issues, and the most nit-picky annoying ones that no one thought to test.

The goal of QA and UAT is to break the site… the code.

Self-QA

A major part of the QA process during development is doing it yourself. Remember that you, as the developer, are responsible for being the first set of eyes reviewing your code. Unfortunately, you can code a feature for so long that you become blind to obvious issues.

Slow down. We do have deadlines to meet, but a quick break from your code can really help. Taking a lunch break, stepping away from the screen for a few minutes, or even working on another task for a bit can get you refreshed for self-QA. You’ll be able to see the little things you can clean up, fix, or completely change for clarity, because you’ve taken a quick break from your code.

Another method of self-QA is to take the feedback you received at the end of your last project and apply it to new code. Do you consistently receive the same feedback on issues when a formal QA is done? If so, keep track of that feedback and include it as part of your initial development.

Peer Review

When you need a second pair of eyes, use your peers. If you’re building a large feature, using a new skill set, or just want some additional feedback on a task before turning it in for final review, grab a peer to review your code. If you’re working with a team, lean on them to make your code better and expect them to do the same with you. We should all have the same goal, produce the best possible product by writing the best possible code. 

Here at WebDevStudios, we have a system in place for our peer reviews. A developer will work on a feature and pass it to a senior developer for the initial round of code review. If everything passes their checklist, they pass it onto the a lead developer for final review and scrutiny.

A senior or lead developer may not have all the skills to get your code up to par. This industry changes so rapidly that no single developer can truly know everything. If you see code that a senior or lead developer can improve upon, let them know; and hope that you work in an environment, like WebDevStudios, that encourages knowledge sharing.

Formal QA and UAT

Once self-QA and peer review has been completed on individual tasks within a project, it’s time to do a full project QA and UAT review. This process will most likely be unique to your company or team structure. The general process is that an individual, or team of developers, reviews the entire site to perform visual and functional QA.

Visual QA and functional UAT processes may be completely separate from one another. Comparing a page in the browser to the mock-up, and running through a specific set of functionality, like new user registration, are two entirely different things. It is critical to perform both QA visual review and functional UAT.

As a freelancer or company, you also need to define your own pass/fail scenarios on visual QA. Do you want to strive for absolute pixel perfection, or is it okay for the placement of something to be off by two pixels? Will it be important to the client to take the time to take screenshots, write up a task, have it assigned out, worked on, and finally reviewed?

What isn’t subjective, though, is whether or not a thing actually works. This is where a strong-handed UAT comes into play. Before you can have a solid UAT process, you need to have a solid process for documenting how something should work. This can be either with user stories defined by the client in the project plan itself, or documentation written as the project progresses. If user stories are in place from the beginning, that means each developer knows exactly what they need to do in order to complete their work. Providing user stories can be a major cornerstone along the QA and UAT process.

Client QA

Once an internal formal QA and UAT is completed, it’s time to hand off the completed project/site to the client so they can run through their review and testing process. Each client is unique and will have their own QA and UAT review processes to ensure their site is functioning as expected, per the proposal, prior to a production release.

Clients are typically able to find bugs when they run their QA. Clients have very specific ideas about how things should look, function, and how they should be able to interact with elements on the site. Certain features or functionality may not have been conveyed in static mock-ups. For example, the way images or links hover, or how unique sets of content resize for small screens. This is where user stories can help to eliminate some of that disconnect between static mock-ups, and a fully functioning website. When clients find bugs or issues based on expected functionality, we consider this a learning experience. We have the opportunity to improve our processes so that we can improve on assumptions for the next project.

Conclusion

There are so many methodologies around what we do and how to do it more efficiently – whether it’s making sure your code is as clean as possible, or that your functions do just one thing. These are hallmarks of being a solid developer. But, if you’re writing clean, smart code and testing it in different scenarios, you’ll wind up with fewer issues in the various stages of QA down the line.

QA is not a single process run at the end of a project. In reality, QA happens at several points along the way, starting with the developer working on the task and performing self-QA, peer reviews with senior and lead developers, onto the person running internal QA, and finally in the client’s hands. The earlier an issue is caught, the better it is for everyone along the path of review. It’s so important to be able to reflect on your previous projects and apply the knowledge you’ve learned at the earliest stage possible.

What are your methods for QA-ing your work on a site from start to finish? Do you have suggestions or tips on how others could possibly benefit from your own workflows? If so, share them in the comments and let us know!

The post The Importance of QA and UAT appeared first on WebDevStudios.