I assume ‘every’ fellow Tester in my network have experienced this situation at least once in his/her career. One of the most common Testing situation – How do you handle timeline crunch? Since Testing is the last step before client demo, the Test team has to make-up for the delays encountered till the build is deployed in Test environment. Now how do you handle crunch timelines without impacting the quality?
One of the most common situation, how will you start Testing without any functional requirement specification or any related documents? No wonder there are sometimes these kind of situations, ex. Resource attrition, no-documentation-with-agile-projects, etc. The only hope in these situations is ‘Exploratory Testing’. Since there are no documents to refer, refer the application directly 😉 Explore it, Test it. Gradually the flows make sense and we actually start testing it. Other option is to sit with Business analysts and developers to get application understanding – listening to experts instead of reading a document.
How come you are able to find defects in already-tested flows? As an end-user there are numerous possibilities of inputting invalid data and then expecting correct behavior.
Exploratory Testing has gained popularity in past few years. There are several studies and has also received much of professional attention from the industry. Exploratory Testing gives power to the tester together with responsibility; it offers great freedom and opportunity to the tester for exploring and identifying areas for improvement. But why do we need exploratory testing if we’re already doing a good level of scripted testing? We’re writing test scenarios in each story, running them on different builds until they all pass, and we’re also running them in regression to make doubly sure that the product is still working. Sound good and thorough – what’s the point in doing more software testing on top of that? Well, there are a few good reasons to do exploratory testing in addition to the regular, scripted testing. It exposes the underlying issues within your product, app or website and allows testers to literally explore the functionality.
Industry is sure moving to Automated Test execution. But as I say – Automation is confirmatory, Manual tests are more exploratory. Only Automation testing is not enough, so testers need to be good at finding bugs. “Finding Bugs” is one characteristic that differentiates a good tester from a mediocre tester. The basic principle is to combine things that programmers didn’t expect with common failure modes of your platform. Always remember, Testers don’t break the software. It is already broken. You just need to find those broken pieces and help make the software better.
Most of us have had an argument with friends or colleagues about which route is fastest from home to office or vice-versa. How’d you settle that bet? Yeah! Test it out. Leave the same place at the exact same time, via separate routes, and find out whose way is the best. Hope you got a brief idea about AB testing 😉 which is used by today’s designers & marketers to gain insight into visitor behavior and to increase conversion rate. Though one of the easiest and most effective technique for optimization, A/B testing is still not as common as Internet marketing subjects as SEO, Web analytics and usability. People just aren’t as aware of it. Let’s explore more about AB Testing.
Continuing on our previous article on Verification & Validation – we know that they are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. Verification involves all the static testing techniques whereas Validation is more of Dynamic Software testing. But what is Dynamic testing? Dynamic as in lively and active. And when do you think a software is active? Yeah! When users are actually using it.
In software project management, software testing, and software engineering, Verification & Validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. In the context of testing, “Verification and Validation” are very widely and commonly used terms. Most of the times, we consider the terms same, but actually the terms are quite different. In this article we will first explore Verification vs. Validation and then move on to its practical application in Software Testing.
Static, as in Stationary or Stagnant. What do you think is stationary in software terms? Yeah! The code. Either it can be stationary – or running, i.e. when you run the code. As the name suggests Static Code Testing is one of the software testing technique where the code is stationary, i.e. NOT running. How? Simple, you don’t execute any functionality (or code). Then how does it ‘test’ the system, you may ask 🙂 In Static Code Testing we don’t execute the code, instead it is checked manually or via tools for any design defects. As you might have guessed – Static Testing is not just limited to the code, we can even analyse the associated documentation like requirement & design documents to identify any potential errors or standard violations. Static testing is also known as Dry run testing.