Tag: test plans

Posted on

Rough test plan for my first indie SDET project

In order to keep my SDET skills active, and to have something I can point hiring managers at, I’m going to do some test projects that will use this very site as the test bed. Here’s a rough plan for how this is going to work.

Requirements

  • Using Python, write a small Selenium suite that will test dev.annathepiper.org from the front end.
  • Using Java, write a separate suite that will use standard WordPress API endpoints to verify the site.
  • Also using Java, since I did this recently in a research task at my last job, show how I’d do Selenium-based testing against the site. Use Selenide as the framework for doing this.
  • Version 1 of this project should be a BVT-level thing that will be testing basic front-end things like “are there pages?” and “are there posts?”
  • Version 1 from the API level should be essentially testing the same BVT level things, only querying via REST as opposed to hitting pages on the site.
  • Stretch goal for the front end: a test that verifies you can leave a comment on a previously existing post.

Test Environments

  • Ubuntu, since that was the environment I most often worked with in my last position.
  • Windows 10, with the Ubuntu subsystem installed.

Both of these are installed on Savah, my dev box, which dual boots between those two operating systems.

Additional tools I plan to use:

  • For the Java code, I’ll be using IntelliJ as that’s what I’m most recently familiar with.
  • Within IntelliJ, I’ll be setting it up to run the tests as a TestNG suite, but also through Maven.
  • For the Python, I will also be doublechecking if IntelliJ will let me deal with Python. If it doesn’t, I will be doing one of two things: investigating PyCharm to see if I like it, and failing that, installing Eclipse. (Eclipse was the last thing I worked with in depth for Python code.)
  • For manual verification of any WordPress endpoints I want to play with, I’ll be installing Postman.
  • I will be installing a local instance of Jenkins to demonstrate my familiarity with running automation jobs via that.
  • For Selenium server purposes, I’ll be installing Docker and the official Docker Selenium images. I’ll be experimenting with whether I will do a standalone Chrome or Firefox image, or setting up a grid via Docker-Compose. (Prior experience with researching this suggests it’ll be the latter.)

What I’ll Do With the Code

I’ll be creating the Python and Java projects as two separate repos up on my GitHub account (taking steps to make sure that any information I don’t want to reveal about account credentials doesn’t get included).

I will include documentation. And, time permitting, perhaps a Powerpoint slideshow to talk about it.

More on this as it develops!

Posted on

My history with test plans

My last position was pretty standard in terms of how testing a project went. Something like this, in a rather loose implementation of Agile methodology:

  1. Project management, Dev, and QA got together to go over a project concept and discuss what it was asking for. Usually, but not always, this would involve reviewing a BRD (“business requirements document”) or a spec. These could involve wireframes from Design, actual mock screenshots, written expectations for how a thing should work, or all or none of the above.
  2. Sometimes in the same meeting, or sometimes in a different meeting, we’d discuss the logistics of how to implement the desired functionality.
  3. Dev and QA would then task out the expected work. I am familiar with using points to scope out the size of a task, but at this particular position, we mostly just scoped tasks as “this will take me X number of hours to do”.
  4. Once we had the tasks, we’d agree who was expected to perform what, and see how long it would take us to accomplish them so we could commit to a release date. Sometimes this would take us just a single two-week sprint, maybe two depending on how long Dev would need before handing off to QA.

Now, as a member of the QA team, it’d be on me to work with the expected plan for how to test things. Usually this plan would be whatever set of tasks we’d committed to for any given sprint, and we’d take care to write out within each task what the expected work would be. These tasks would often be based on the BRD of whatever we were testing.

But for larger projects, particularly ones where we’d need to pull in external help, we’d often write out actual test cases to use for reference. The tool we most often used for this was TestRail.

Why do I mention all of this?

Partly to go into a bit of detail about my most recent experience with testing, so that I can be able to coherently describe it for later interviews. But also because I want to lay the groundwork for how I plan to do a couple of test projects against this very site.

More on that in forthcoming posts.