What is Smoke Testing?

Smoke testing, also known as “build verification testing,” is a type of software testing that is used to determine whether a build is stable enough to proceed with further testing. It is a quick, superficial testing method that is used to identify major issues that need to be addressed before more in-depth testing can be done.

Smoke testing is typically the first level of testing that is performed on a new build of the software. It is meant to be a high-level test that checks the most essential functions of the software to ensure that it is working as expected. The goal of smoke testing is not to find all of the bugs in the software, but rather to identify the most serious issues that need to be addressed before the software can be tested more thoroughly.

Why is Smoke Testing Important?

Smoke testing is an important step in the software testing process because it helps to ensure that the software is of high quality and ready for further testing. By identifying major issues early on, smoke testing helps to save time and resources that would otherwise be spent on more in-depth testing of unstable builds.

Smoke testing is especially important in agile software development environments, where new builds of the software are released frequently. By performing smoke testing on each build, teams can quickly identify any major issues and fix them before they become bigger problems. This helps to ensure that the software is always in a stable and reliable state.

How is Smoke Testing Performed?

Smoke testing is typically performed by running a set of predetermined test cases on a build. These test cases are designed to cover the most important functionality of the software and are meant to identify any major issues that need to be fixed. The test cases for smoke testing are usually selected by the development team and are based on the most essential functions of the software.

When performing smoke testing, testers should focus on testing the software’s most important features and ensuring that they are working as expected. It’s important to note that smoke testing is a simple testing method and is not meant to find all of the bugs in the software.

In the context of Tester Work, smoke testing refers to the process of testing a new build of the software provided to ensure that it is stable and ready for further testing. This might involve running a set of predetermined test cases on the build to cover the most important functionality of the software and identify and report any major issues that need to be fixed.

Here are the steps for performing smoke testing:

1. Obtain a new build of the software: In order to perform smoke testing, you will need to have a new build of the software that you want to test. It will be provided by Tester Work after you have been invited to the smoke test.

2. Identify the most important functions of the software: Before you begin testing, you should identify the most important functions of the software. These are the functions that are most essential to the operation of the software and should be tested first.

3. Create a set of test cases: Next, you should create a set of test cases that cover the most important functions of the software. These test cases should be designed to identify any major issues that need to be fixed.

4. Set up the test environment: Before you can begin testing, you will need to set up the test environment. This may include installing the software, setting up any necessary hardware or software dependencies, and ensuring that the test environment is configured correctly.

5. Run the test cases: Once the test environment is set up, you can begin running the test cases. As you run each test case, pay close attention to the results and make note of any issues that you encounter.

6. Report the bugs: As you run the test cases, be sure to report any bugs that you find. This will help you to be the first one to report the issue and receive the payment if it is accepted.

Conclusion

Smoke testing is a crucial step in the software testing process that helps to ensure that builds are stable and ready for further testing. By identifying major issues early on, smoke testing helps to save time and resources and helps to ensure that the software is of high quality. It is an important part of any software testing strategy and should be performed on every new software build.

---

This article is the sole responsibility of the author. By submitting their work to our blog, authors affirm that the content is original and does not violate any copyrights or intellectual property rights of third parties.

Hello,

 

Quality Assurance is the term that I have been experiencing for almost 10 years. After my bachelors in engineering, I had no clue on how to shape up my career. I attended a few interviews at a few tech companies and got selected by one. Being a fresh graduate, I was skeptical about my abilities & passion. After months of training at my first company, I realized that I possess some skills using which I can contribute to delivery of software projects and do good to society & to myself :).

 

Firstly, I started working for a dutch airlines company, where I had to do quality assurance for web services. And for the first time, I heard the word agile. My first feeling was like..ah..lets do it. After a few sprints, I noticed that I had been using skills like analytical ability, critical thinking, and communication. Moreover these are the skills that kept me recognised and delivered what I had promised. I felt very proud. In the back of mind, I decided that Quality Assurance is my way forward.

 

I worked a few years at this airline, improving all my skills being a QA. Be it in business analysis, test analysis & design..everywhere I saw opportunity for my growth. I have also tried and learnt quite a few automation tools. Also did a few QA certifications to really know what QA is on paper. Later I joined a fintech organization and started seeing a few other sides of QA namely testing in different platforms, clouds. I am very happy to experience and participate in different test types, test levels.

 

No matter how many years of experience we have, whether we do quality assurance manual or automation, we are always using our inherent & underlying skills in our day-to-day life. Those skills are..

Analytical ability is something that we use everywhere as QA. Be it for test case preparation, test strategy preparation, root cause analysis, defect reporting, causal analysis and last but not least business analysis. I think this is one of the most important abilities of any QA Engineer, which helps him/her to analyze businesses before any one in the market does. As a side note, I feel it’s one of my adrenalin high factors till date.

 

Critical thinking is another arrow for any QA, which we use in our daily life to assess the situations, application behaviors around him. We always train our QA mind to be fact based, unbiased. In simple words, if we raise a bug, this is the skill that pushes us inherently and makes a judgmental call. And moreover, if a customer or developer questions our bug, we are always positive and open to conversation. So let’s always be reminded of our very own ability, Critical thinking.

Communication skills are another skill, which every one of our QA community possesses. We use it in daily life in understanding businesses, requirements and in discussions with our product owners, business analysts, test leads. Our effective communication is especially visible to everyone in our way of writing test cases, test steps, defect’s steps, expected results and actual results. Presentation skills are also very important skills that every one of us use when presenting our results and maturity products using QA metrics.

 

First two weeks of freelancing @TesterWork

 

After experiencing all of this over the past few years, I have now joined Tester work as a freelancer. To be honest, I got to know about TesterWork from a blog I read. 

With a skeptical mind, I just went to the website & spent quite some time going through FAQ’s and understanding what it means to be working at Tester Work. Two days later, I decided that I was going to go for it. Onboarding process was smoother, I just needed to register online and do an online assessment. Within days, I got the news that my assessment went well. Later I waited for a few days, and then I got my first invitation to test. 

To be frank, I thought I needed to raise a lot of bugs to get  recognized quicker. But then I read a few of the experiences in blogs and they made me rethink and go back to basics of applying the above said basic skills and do good for our customers. I went through the test instructions which were quite clear, I just needed to follow them and in case of questions, an email would solve my questions. 

 

Happy to be part of the TesterWork community. Hoping to experience a lot more in the coming days & write more blogs.  

Apply Risk based testing for Software Functional Tests

 

Introduction:

Risk based testing has been talked about for some time now. This article attempts to detail simple ways to apply this methodology and looks at how testers can use this methodology for testing in appropriate situations. While Risk based testing is a vast subject that needs the use of Scientific methods and techniques for testing, this articles provides a sneak peek into the subject.

 

Questions that come up related to this:

1. How is this different from the normal testing methodology and approach?
2. Which projects and circumstances can this be applied ?
3. What techniques can be used as a part for this methodology ?
4. What are the benefits that will accrue from this methodology ?
5. Can this be applied to all testing projects ?
6. Do we need to look at only Product risks or at Project risks also ?
7. How can we generalize risk areas across projects ?
8. How can we ascertain the product risks even before getting to know the product features and technology?

 

When it can be applied- Use cases:

1. The software has been tested earlier and the user is aware of the areas that are prone to defects, high risk area.
2. The user has tested the software before and knows the areas that have gone untested, or the testing of a few features that has been accomplished using work arounds.
3. Testing has been done but with workarounds and lack of test data
4. Testing for certain areas was done partially due to the lack of integration with external systems
5. Testing for a few features were not done due to lack of test environment
6. Testing has been done but testing for a few features had been deferred
7. Can be applied during regression tests
8. There is a time constraint and shortened schedule/ period to test a software and hence some urgent critical area tests need to be achieved.
9. The user is fully aware of the business domain and can use their knowledge to focus extensive tests for specific areas
10. Mission critical apps have to be tested risk based in addition to the regular multiple rounds of testing
11. User is aware of the product features and can foresee the risk areas within the product
12.  Observed that there are a lot of defects / bugs getting reopened during the retest and regression tests.

 

How it can be applied -Use cases:

 

Use case 1 – There are areas in the software that require complex calculations and hence this area is classified as high risk and tested extensively

Use case 2 – There are areas/ features  in the software that had a lot of defects and hence regression and retest of these features are warranted

Use case 3 – There are features / areas in the software that has integration with external systems and hence are high risk areas need to be tested extensively.

Use case 4 – There are a lot of dependency between the features or functionality in the software and hence these areas need to be tested extensively

Use case 5 – There are tests that require specific data or long drawn conditioning of data to achieve the test, hence these areas are identified as risk areas

Use case 6 – There are time constrains to test and hence important customer facing features and main functionality needs to be tested extensively, while other low priority tests can be deferred for later.

Use case 7 – In mission critical applications all areas are high risk areas and need extensive testing

Use case 8 – Customer dissatisfaction will be triggered if certain features contain defects and hence these need to be extensively tested.

Use case 9 – Frequent changes occur to the Application Under Test and hence regression areas need to be identified and classified based on risk to plan the tests

Use case 10 – There are features in the application that have financial implications and can cause financial loss, and hence classified as High risk areas for extensive tests.

Use case 11 – There are data intensive tests that need to be classified as a higher risk for testing

It is time to hunt bugs! Let us talk about exploratory test

On exploratory testing projects, we will give you the freedom to explore an app/website by yourself to identify all possible bugs you can find. Fear not! We are not talking about insects or animals, a bug is a problem in a piece of software that causes unexpected results or makes the app/website crash.

Let’s tackle some common myths about this type of testing, so you can feel confident when you receive an exploratory cycle invitation.

Myth 1: There are no rules to follow in exploratory testing

WRONG! As in any other cycle, we always encourage our testers to read the complete description of the project – including the Overview and the In Scope/Out-of-Scope areas for testing. In fact, one of the main clues to become a skillful tester is your capability to read and follow instructions. Do not rush; if you miss something important in the instructions, you may waste your time!

Make sure you understand the complete description of the project before starting your hunt, and do not forget to read the Out of Scope Section carefully, as there might be parts of the website/app that you are not allowed to test.

Myth 2: It does not require previous testing knowledge

If you are a new tester, we do not want to discourage you from joining these cycles. On the contrary, we want to provide you with the necessary tools to succeed on your first hunt!

What is it that you should know before joining an exploratory project? You need to learn how to report bugs; we rely on your written skills and your capability to meticulously report issues so we can easily reproduce them afterwards by following your instructions.

A complete course about bug reporting is available at the Testerwork Training Center or Academy for you to review anytime!

Myth 3: Exploratory tests are time consuming or take longer to complete than other types of testing

When following the corresponding Overview instructions, exploratory testing should not take longer than other types of projects. In fact, by having the freedom to explore an app/software, you also have the possibility to set up your own schedule. Keep in mind that the key to success is not the quantity of errors you find, but the quality of your bug reports.

Saving time with the right screen record setup: Valuable tips to screen cast on your PC

If you are reported any bug, you understand how valuable the report you create is. Speaking for myself, filling Bug Reports is a time-consuming task, not only because of the whole written description of the Bug, but mainly because of the visual proof of the bug. Specially when you are a beginner, making the 

Yes: let’s talk about videos and pictures in the article!

I would like to share with you some apps that help me a lot when collecting the evidence of a bug. In this article we will talk about two tools for desktop devices that completely changed the way I test. I will not only present the tools, but also help you to set them up in order to assess their full potential. Mobile users, don’t get mad at me: we may discuss some tools for you another time, okay?

Screen Record: OBS Studio

One of the reasons why I use OBS Studio to record my screen while testing. It is a free, open source software with multiple features, from simple screen recording to streaming. It is available for Windows, MAC and Linux, and it’s free! It does not leave any watermark on the final video and it doesn’t have any limitation on the video length, but these are not its stronger features. Let’s break them down to four key points.

1. Creating Scenes and Sources

One can say that a screen recorder that captures the whole screen is enough for testing purposes, and that’s right. But remember: the point here is to be more productive as a tester, and that can be achieved by using different scenes and sources for the video input.

One of the pain points while testing on Windows, at least for me, was to conduct a guided test case without recording any of the test case documents (do you know that we are not supposed to do that, right?). Sometimes the test case was a little complex and required several sequential steps. Instead of using a second device only to open the test case document, I simply added another scene on OBS Studio and then selected Window Capture as the source. With the test case document in a secondary browser, I’m then able to continue testing while recording only the app in scope.

However, if the test required more than one window to be recorded (like testing simultaneously with two browsers), then I only needed to change the source to Display Capture. Usually, I keep two pre-settled scenes, each one with a different source, so I only need to switch between the scenes while testing. You may also notice that there are several other options of sources, but those two options already worked just fine for testing.

2. Setting up the video output

Knowing that the Tester Work website has a limit of 200MB per video, recording the screen with the convenient resolution can save you from a video editing task. OBS Studio has several settings that can be customized based on the user’s preferences. Setting the video format as .mp4 and the Recording Quality as High Quality, Medium File Size usually is enough for uploading on Tester Work.

You can also change the video resolution and bitrate, and even modify the name format of the video that is being recorded. That way your video is ready to be submitted as soon you finish the record.

3. It’s free

Did I already mention that? I think it is already clear at this point…

4. Using shortcuts 

This may sound a little bit perfectionist, but I just don’t like to record the screen and the first image we see is the screen recorder window. I know, that is not a problem at all, but having a clear recorder makes the job of the test cycle moderators easier. Imagine yourself with dozens of bugs to be reviewed, you would prefer to have records that go straight to the point. You know, less is more.

You can set up some shortcuts in OBS Studio for the functions that you use the most. The good thing is that they work even with the software in the background. What I do then is to set up some shortcuts to start, pause, resume and finish the recording. That way I can start my recordings directly on the app to be tested, simply by pressing the pre-defined shortcut.

I must also say that having a pause/resume function is pretty handy, especially when I forget any info of the test case document, such as an assigned account to log in. It also helps if anyone interrupts you during the test – if you have kids at home you know what I’m talking about. Of course, sometimes you will need to go from start to end without any pauses, but being able to pause the record is really helpful.

Screenshot: Lightshot

Some types of bugs do not require a whole screen record to be clearly reported. Take the Translation Feedbacks as an example: recording the whole flow is pointless if you only need to highlight a single word or sentence.

When I started testing and I encountered any of those bugs, I hitted Print Screen, opened any image editor, pasted the printed screen, edited it to highlight the bug, and only then I was able to submit it.

But, what if the image editor was embedded on the Print Screen function? That is the premise of Lightshot! And it does it well, you can run it even on low-end devices without noticing any impact on the overall performance. Spotted a bug? I only need to hit the Print Screen button and the Lightshot is activated. You have then to select the area, no need to crop the image afterwards. At this moment, two tool boxes will open.

The vertical tool box is meant for editing. You can add text boxes, arrows, lines and rectangles, or you freely draw them by hand with the pen tool. But do not expect a full design tool with layers, shades and magical wands – you can change the color and that’s all. It is enough to highlight any bug that you find along the way, though.

The horizontal tool box is used for saving. Here you may not only be able to copy the printed image with edits, but you can also save them in a local directory, share in social media, and even perform a reverse image search on Google. For testing, saving the image will be enough. If you prefer to go through the flow as fast as possible without long pauses, you may be interested in saving the images without edits and use a third party app to highlight the bug later.

OBS Studio and Lightshot are only two available tools to make us more productive as testers, not only to have more time to dedicate to bug hunting, but also to create reports with higher quality. There are several other tools that can be used, with additional features like mouse highlighter. If you have any remarks, let us know in the comment section below.

 

Happy testing you all!

Gustavo

Did you have any QA experience before joining Tester Work?

Yes, it was more than 3 years that I was already working as a tester in my free time, so when I joined Tester Work I already had a deep knowledge of testing processes.

 

Approximately how many hours a week do you test with Tester Work?

It strictly depends on the number of available projects during the week, but usually from 15 to 30 hours per week.

 

What are the first things you do when joining an Exploratory Test Cycle?

 The first thing I usually do is read all the received details about the cycle, in order to know immediately what’s in-scope and what is out of scope. This lets me avoid reporting invalid bugs and helps me to concentrate on relevant issues.

 

During ongoing test cycles, do you focus on the number of reported bugs or the quality of your reported bugs?

 I would say half and half: testers sometimes are very fast in bug reporting when the cycle is activated, so it’s needed to balance quality with the reporting speed, trying to report bugs in the most precise way in a short time.

 

Have you ever had a difficult situation to face during a Tester Work test cycle?

Yes, there are times in which it can happen that you receive multiple cycles all at the same time, on different operating systems, so you have to split yourself testing on multiple devices at the same time without confusing one test detail with the other ones. In this case, I usually start and complete 1 test at a time, before starting another one.

 

How do you make sure you’re keeping up with the best QA practices?

When I’ve some free time, I like to read and read again guidelines and youtube videos about testing, so that I can always keep up with the most updated QA practices.