Sometimes Doing it Old School Works Best

The truth is, I'm really bad at keeping track of the things I have to work on, things that I have worked on, deadlines, etc. I've tried to utilize apps and programs of all kinds as well as notebooks and sticky notes. Nothing seems to be very effective for me. But, I think I've finally found my solution. While I'm only two weeks in, it's been far more successful than anything else.

My problem with programs and apps is that I test programs and apps so I almost always have my work up on my screens. And I'm a window maximizer. I don't like having four or five things showing on one computer screen. So in order check my To Do list or record an activity, I have to switch from my work to something else. That may seem trivial but for my simple mind, it's apparently very disruptive. Consequently, I've been using a notebook because for me, I don't have nearly the same level of mental disruption to scribble something down quickly. Notebooks, however, get to be very messy and disorganized.

My solution: an appointment book. It's not just any appointment book but it's also not an extraordinary book either. What I have is actually a weekly calendar. The left page has 6 rows for each day (Saturday and Sunday share a row) and the right page is just a ruled page for miscellaneous notes. My particular system is to have a two columns one each day. The left column is my To Do list and the right column is my Accomplishments list since planned vs. actual is almost never the same. The ruled page is there to note information I want to keep handy for the week not for keeping notes during testing. The book itself is hard covered which makes it usable away from the desk. It also lies flat and open so it's easy to reference no matter what I'm doing.

The moral of the story is, if one method doesn't work for you, try another until you find the one for you. And the best solution might not be the most technologically advanced, which is okay. So far, this has been working really well for me, which I think my boss @kelleykoehler is very happy about, perhaps an appointment book like this would be helpful for you too.

What should be the easiest archaeological dig in the world

When I entered the field of software testing, the last last thing on my mind was archaeology. Software testing is about the future whereas archaeology is about the past. Technology is clean and non-physical but archaeology is dirty and labor-intensive. However, the two fields aren't all that different. A good software tester is going to thrive on artifacts, but not the kind buried in the ruins of ancient civilizations.

In software projects, an artifact is any piece of documentation that relates to the project:

• RFP
• RFP Response
• SOW
• Project Plan
• Requirements
• Design comps
• Story boards
• User personas
• Test scripts
• Defect reports
• Meeting summaries
• etc.

The artifacts mentioned above help software testers the same way bones help paleontologists. Both are vital in the acquisition of knowledge. Testers need to have a thirst for project knowledge. How can one assert if the product works as intended without having an authoritative source? Regardless of approach, the more the tester knows about how the software is supposed to work, the more thoroughly they can test through broader coverage and more intricate scenarios.

When projects don't have a decent amount of documentation, you're asking for scope creep and unsatisfied client expectations. Testers, get dirty and dig into the documentation. Insist on having access to it and demand it early. Study it thoroughly. Use it to help design your tests. If the documentation doesn't exist, consult the project experts (well, consult them anyway) and then write it down. Once it's written down, it can't be disputed - it might be changed later but that can happen to any document. Moral of the story: use everything at your disposal to learn about the project.