3

I work on testing a web-based financial application. Usually as soon as the Business Analyst publishes the first version of the 'Functional specification/requirements' document, I as a black-box/manual tester start to analyze it.

The document usually describes the behavior of a new module/enhancement in the product and page-by-page examples of the UI screens. Also,business validation scenarios, rules and impact on existing functionality/features.

Now, I usually write my Test cases/Scripts directly based on the project specification. I don't create any test scenarios document as such.

I want to ask how I can become more effective, better at analyzing the requirements as a QA engineer? How can I find more issues in the requirements and be more valuable for my company?

I would appreciate any practical ideas, tips, books, material, websites or any techniques that you might have used and which have helped you in a real-world scenarios

Improve this question

3 Answers 3

Reset to default
0

Use Exploratory Testing

As per my personal experience in multiple mid to large projects, exploratory testing paid me off multiple times by helping me becoming effective & valuable to the team in short period of time, provided done with focused concentration & discipline in a scientific manner.

I was initially surprised to see, by taking a simple QA mindset of "Don't assume anything" and questioning everything(at least first to oneself to understand things) about the application under test, one can find a lot of critical gaps/defects in very short period of time even in the requirement document itself.

Sometimes people with years of domain knowledge miss things where someone with QA(Why?) mindset discovers things fundamentally flawed in a system by simply bringing a fresh perspective and a questioning mindset.

Conceptually 'Exploratory testing' is very simple and can be defined in few words like just Explore, design & test simultaneously but as a tester evolves in terms of QA experience and becomes more observant of identifying specific details & symptoms to find deeper issues, it becomes more & more effective.

  • I consider the following as the typical process of exploratory testing:

Be curious:Ask yourself a question about the product functionality based on common sense/ experience and find out the answer by designing an test and executing it.Always be ready to go beyond the 'obvious' and don't just assume a requirement as mentioned in the document but try to take the perspective of the end user and see why(or why not) something makes sense.

Think on paper: Never underestimate the power of thinking on paper.Write your ideas,make notes ,draw some pictures ,visualize the data flow in the system and make diagrams/mind maps whatever works for you to see clearly the application.Most of the time I keep an simple diary/ pen to keep my notes handy and draw pictures to visualize things.It helps a lot.

Logical Progression: Each question/ answer should lead you to the next logical question.

Timebox Sessions :Do time box(I do 40 mins ) intense sessions and make simple notes of your observations during this process.My primary tool at this stage is notepad.

Be Brave: Don't assume anything and be confident in raising questions about something which does not make sense even though it "seems" fundamental to others.

Improve this answer
0
1

First, I'd suggest you read widely: the blog list at the Ministry of Testing is an excellent starting point and will guide you to more resources (disclaimer: I have published a few articles on their related site, the Testing Dojo). I check their blog list daily, and usually find at least one article that gives me a better perspective.

Second, if you don't already have some kind of reference within your organization that gives you an indication of cross-module impact, I'd recommend starting one. It doesn't need to be fancy: For my current position I wound up writing a wiki guide that sums up what can be affected by changes to each module. It does take intimate knowledge of the system in test to write this, and you will be constantly updating it, but the effort is worthwhile just to have the reference available. This becomes your regression reference and helps you to ask the right questions about whether a particular new feature could cause problems with an existing feature.

I've also found that diagramming process flows and building mind maps to help me visualize what a new feature is going to do and need helps to clarify where potential issues could arise, as does printing out the specification document so I can read it through more carefully and add bookmarks of questions and possible issues. This method helped me most when I was working with a strict waterfall lifecycle and had to deal with specification documents well over 100 pages in length.

What works best for me is a goal of knowing enough about what I'm working on and with to be able to connect the missing pieces and look for missing pieces. This may be an individual thing, but I have found that a combination of deep domain and product knowledge combined with a focus on gaps and assumptions in the documentation finds a lot of issues before they can become serious code problems.

Improve this answer
0

One thing I suggest is using some of the developed industry standards and terms to help give input to the process. Use and share these conventions and approaches with the business so you can help guide them to write good functional specifications and not just be the recipient of their specification which may not include some of the goodness below. This is also part of the 'shift-left' movement of testing where automated engineers ('testers') are involved right from the start and in creating the initial requirements and tests for them.

Examples:

Use the terms 'happy', 'sad' and 'optional' for the test cases. Happy being the 'everything works correctly' path/workflow, sad being the workflow where either the users and/or the system makes an error. Optional is non-required information that is not required for the minimal workflow and can often be missed by simple happy and sad cases. Optional cases are also either happy or sad themselves.

Use the breakdown of unit / integrated / UAT testing to make sure you are testing the correct stuff at the correct levels. Make sure that complicated business rules and procedures are being well tested with Unit level tests so that you do not have to use the UI to test out numerous combinations of data to see the various cases.

Consider using tools such as Cucumber or RSpec to read human-readable tests that you share with the business to see if they think they are correct. Although some companies have tried to have the actual business analysts write these, over time it usually works out for the technical folks to write it. Largely because as the test suite grows you start to need to use programming approaches to DRY it up and make it sustainable and it starts to become more of a programming problem.

Consider using TDD so that you write these tests cases first and then code is written to make them pass. This is both a huge topic (books written) and a difficult approach. The benefits are huge - the software start to actually do exactly what it was intended. Which should be rare but historically has been common.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.