Have you ever wondered what a code review is and/or what it’s like to participate in one? Are you a tester, product or business person who regularly interacts with the output of the code but wonders if they could catch bugs earlier by “shifting left”?
Turns out you don’t have to know how to code in order to learn about the changes, question the assumptions, clarify ambiguities, and generally participate in the knowledge-sharing around Code Reviews. Here’s a presentation on how to get started and what to look for.
Simply register to gain access, and the video will start right away.
I much prefer the saying move fast and make things better over move fast and break things. The latter might be more popular but the former is more realistic.
Moving fast (software agility) used to be a business advantage but now, at least for any service business, it’s mostly a requirement. Fast implies some things might “break” and while that’s part of the process it should never be our aim. (We should have flexible systems in place to help us quickly identify and fix those “breaks”. Moreover a DevOps culture can help us improve stability so “breaks” are less severe.)
A more realistic mission should be to solve our customers problems and do so in a way that continually improves. Where failure doesn’t mean we stop but rather we iterate until it’s right. This way we solve the customers problems while being able a benefit to our business.
Recently in an online forum a tester person asked:
Does someone have a simple example of test case (excel sheet) format? I am the only one tester in my company and we are trying to arrange the test documentation. Any advice or example will be useful.
I wish someone had given me this advice when I first started out:
Be careful about using someone else’s formatting and/or templates. If you don’t know what you are doing, you might be inheriting their issues and misunderstandings. It’s usually best to understand what you want to accomplish and then find a solution for yourself. Especially if it’s something simple like using Excel for documentation. Tables and matrices are great for organizing tests and don’t cost much money or time to make.
Appropriate Test Documentation
The appropriate documentation for your tests (or test cases) will depend to a large degree on the test technique and approach you use. Test Case Management systems (and similar systems) are often designed for functional or scenarios tests where the format is similar and you can list out multiple steps. Other test techniques such as Path Analysis, Domain Testing and even Risk Based testing can look very different when they are well designed. The same can be said when you decide to take an Exploratory approach to your testing where you are likely to write Exploratory Charters. Cramming all of these different techniques into one system usually isn’t the best idea.
The Smallest Amount
Focus on the smallest amount of documentation you need to do your job well. You have a finite amount of time and if you spend too much of it creating documentation you will have less time to do the work. If you are writing tests for other humans to read and understand, they should be written in a way that communicates this well such as using visuals (mind maps, diagrams, etc.) and summaries. Similarly if you are writing the tests for computers to read and understand they can (need to be) much more granular and step by step.
I’d wager most experienced engineers have gone through this process of: trying to document as much as possible but by the time you are done you didn’t do enough testing and the documentation isn’t done either. Maybe you put it all into a test case management system that no one else cares to read because it’s in this weird format that probably only makes sense to you.
Focusing on the appropriate documentation for your tests and then creating the smallest amount you need to do your job well also allows you to have agility. Agile is all about being able to adjust to changes as they come in. Quick changes in direction aren’t kind on large amounts of pre-scripted documentation and/or can result in lost work.
I wish this approach was more obvious but a quick google search will reveal it’s not the dominate theory. However, if you read this and take the advice you’ll be learning from my mistakes. Focus on using the smallest amount of documentation you need to be successful and making sure that documentation is appropriate for your test choices will give you agility and future proofing even as you scale your team size and move into the future.