Tester’s Adventure

Publikované: 13. júl 2017 15:11

In this blog, I would like to offer all junior testers a closer look at different projects, mainly those, which miss documentation. Follow me on this testing adventure and you may learn a thing or two. Dig in.

In my testing career, I have come across some projects, which are… let’s say, different. Projects might be well-documented with user stories, detailed specification, or they can be with zero documentation, or with requirements that change a lot. In this blog, I want to focus on helping you to choose a suitable approach for such undocumented projects. All testers vividly dislike these projects and try to avoid them, but sometimes, they just come (for example you inherit a project developed outside your company) and you need to act on them!

 

 

Testing regular projects – easy like stealing candy from a baby 🙂 

Let’s talk about a well-documented project first. This type of project is running under the strict principle of Scrum software development process. It has an organized structure with people, documentation, and time management. The biggest advantage of such project is that you have plenty of input information about the subject of testing. You have a written documentation, specification in form of text, diagrams, tables, or pictures. The documentation can be often very extensive. You need to spend some time to read and understand it. However, it provides you with all the details you need for a quality testing procedure. Then, during meetings, which we call refinements, the creator of the specification goes through the description of the functionality and further explains details and connections. During this stage, you ask questions or make suggestions. For example, finding a potential issue in the design can prevent costly fixes during the testing phase. So, the biggest challenge for quality testing is to focus and pay attention to all the available information and apply it to the testing process.

 

Testing projects that are not well-documented – and now the fun begins… 

The other type of a project is different. It´s not better or worse, it´s just different. In this project type, the organization is more vague with very little documentation or with documentation that is out of date, and no refinements. I would call every task a little adventure. Your source of information is the description of the task or source code. This is not every time decisive because there is often a discussion between a developer and a customer in form of comments. In these comments, they often discuss changes of the solution. It is obvious that you have to use other approach and another set of testing skills.  

So, you have your basis from the task description and you have to build on this further. Of course, your biggest advantage is your experience from previous projects. For example, create test cases based on a workflow to test the main functionality. Anyway, whether you have years of experience as a tester or you are just a newbie, following these steps may help you get the most of this testing adventure:

1. Don’t be afraid to ask your (more experienced) colleagues and learn learn learn 

It is an advantage if you have some basic knowledge in the area your software is about. Is it about providing mortgages? Get the basics of the mortgage market. Is it about tracking repair orders? Get the basics of economics. This knowledge will help you understand the bigger picture of what can you expect, and you can create more relevant test cases. It will be easier to get to the particular part of the software which you need to test in a certain test case.   

2. Be fearless, creative and use common sense 

Another valuable asset is common sense, which is helpful not only in professional life. If there is time, you can always discuss the task with a developer. Consider documenting while learning how the software works by taking notes, screenshots, draw flowcharts etc. All this information can help a new team member or you to create test cases. However, don’t forget to document only if it brings value. 

3. Try Exploratory testing, it’s fun 🙂 

Partly, you can use Exploratory testing, because you know what you need to test, but you are not sure how to get to the desired state where you can test it. So, you need to experiment a little bit, explore, try. 

Example: 

Imagine that you inherit a large undocumented project that wasn’t maintained in quite a while. Suddenly, the customer decided on new features. You start by reading the task descriptions thoroughly. Then, you continue with identifying structures in the application and planning test cases and test activities. You are able to see some future problems and suggest a bunch of improvements. You need to consider a level of risk of changes and decide on the number of test cases you will use. It surely is a challenge to test all changes and new features and to make sure there is no unwanted impact on existing functionalities. 

If the software is large and you need to meet a deadline, focus on creating test cases for the main user scenarios in order to cover more bugs in a short time. If the software is integrated with other systems, use test scenarios that cover multiple systems. This way, you can find bugs in more systems. 

So, these are my so-called “two cents” I wanted to share with you. I hope they will help you with testing and make your professional life a bit easier. Remember that no solution is perfect, try to find the right approach and techniques that can be efficient in your project! And most of all, have fun with it.