For this weeks blog post I will be looking at smoke testing.

A smoke test is used to describe a suite of basic tests that verify that the major features of an application are working properly. A most common se of this is simply to determine whether a build is stable and ready for further testing or a final check before you submit something.  The result of this testing is used to decide if what you built is stable enough to proceed with even further testing. The terminology behind the name comes from a similar type of hardware testing in which the device passed the test if it did not catch fire the first time it was turned on. The testing covers most of the major functions of the software but none of them in extreme depth. The result simply is whether or not you must go deeper or not. If it fails you stop further tests and try to fix what you already have. This testing helps expose integration and other major problems early in development cycles. It can be conducted on both newly created software and enhanced software. A smoke test is almost always performed manually with some help of automation tools or scripts but if the builds are prepared frequently automated smoke testing is the best to use. After an application becomes more developed and mature in a sense with more functionality the smoke test will need to be made more expansive. Sometimes even just one incorrect character in the code could render an entire application useless. The advantages of this smoke testing expose integration issues and helps you uncover the issues early.

 

http://softwaretestingfundamentals.com/smoke-testing/

For this week’s blog post I found a blog that shows you how to reproduce a bug in your application. Why is this important? Well if you see something wrong in your application but cannot reproduce it this blog may help you with it. An obvious but important step to undertake is to simply gather information, and as much of it’s you possible can about the circumstances of the issue you are looking for.  Retracing the steps just before the bug appeared is a good way to do this the same goes if someone else reports the bug. Pertaining to another person reporting the bug is it a different operating system their using? A different browser or a different browser version? Again, obvious questions to some but to others they might not think about it. Keeping track of what changes, you have made trying to reproduce the bug is very important, knowing what you’ve tried and haven’t is crucial. I know this is something I would probably not keep track of which would cause me a lot of frustration. Going off of this using logs and developer tools are extremely helpful in providing a sense of direction in the behind the scenes of the application. If using a browser, especially chrome, you can simply go to the top right and find all the developer tools by clicking the three-dot menu. The blog then lists numerous factors to consider when trying to reproduce a bug, here I will discuss a few. Going back to the user end of bug, did the user not have the correct permission or a specific permission level? If so, you may be dealing with a bug that is only seen on an administrator level or by a certain type of customer. Authentication may be something to take into factor if the user cannot log or such. what is the state of the data that the user has? Can you reproduce the state exactly? The bug may only appear when a user has a very long last name or a particular type of image file. Another simple factor is configuration-based issues. Something in the application may not be set up properly. For example, a user who isn’t getting an email notification might not be getting it due to email functionality being turned of for their account. Checking all of the configurable settings in the application and trying to reproduce the issue with exactly the same configuration is the best way to check for this. Another issue some may not think about are the race conditions. The best way to determine if there is a race condition is to run your tests several times and document the inconsistent behavior. Clicking on buttons or links before a page has loaded in order to speed the input up or throttling the internet connection to slow the input down are good ideas for this. The last one they list is a simple machine or device based issue. This is probably the most common one that we face in all honestly, we’ve come across it a few times this semester even between Mac and Windows. Essentially something is working on Mac then is transferred over to a Windows device and does not work since it was originally made for a Mac and didn’t consider something small that windows does not have and more. After reproducing the bug you want to narrow the steps down to make it as efficient as possible making it easier for either you or the developer to fix in the code in the future.

All and all I thought this blog was actually pretty helpful at explaining steps on how to reproduce bugs and to help find them and make your testing process a bit smoother..

http://thethinkingtester.blogspot.com/2018/12/how-to-reproduce-bug.html

Angular Unit Testing

For this week’s blog post I thought I would take a look at Angular Testing considering in class we have been discussing it and are going to use it for our final project. From the site I found they go into great detail as why it is good to use angular and overall how to conduct it properly. They first start off by listing an example of code that complies properly and “works” but under a more complex situation with dozens of tests in a suite it may begin to fall apart. They go on to explain that for every run it will recompile the components and operations taking up to 75% of your time recompiling and not actually running the tests themselves. Next, they show an Angular Testbed monkey patch that will patch the testing framework resetting the testing module before each run and each test. The TestBed.resetTestingModule function they use will clean up all the overrides, modules, module factories and disposes all active fixtures as well, essentially cleaning up what you have. A _initIfNeeded function then comes into play , preserving the factories from the previous run doing what they need to do. If the flag is false the TestBed function will re-create components required for the test, creating a new zone and testing module but not recompiling anything if moduleFactory is in its correct place. After this they run the code they have, clocking in at a 24 second run time to complete its test suite. Then they apply the patch by calling a setupTestSuite function and replacing beforeEach with beforeAll causing the run time to become 8 seconds. A notice 3x time increase in time efficiency for this certain example. With this patch it allows them to preserve the compliation results and re-use them for multiple test per suite.

After this they start up Karma parallel tests, allowing for the tests to be run in parallel. This website shows all the code which is quite lengthy and I wouldn’t want to subject you all to a blog post that takes up too much space. By clicking the link below you can see all the code they have and more. All and all this website was pretty handy and interesting with what they described and how to show angular to its potential.

https://blog.angularindepth.com/angular-unit-testing-performance-34363b7345ba

 

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

 

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

Acceptance Testing

For this week’s blog post I will be discussing another form of testing called Acceptance testing. Acceptance testing is a form of testing where a system is tested for overall acceptability. The reason for this is to see if the systems compliance with certain business requirements and assess whether it is acceptable for delivery. The site shows a helpful diagram illustrating when you uses this testing, with Unit Testing on the bottom, Followed by Integration testing above that, System testing above that and with Acceptance on that the top of that one. The site also gives a good analogy of what it is exactly happening with the illustration. During the process of a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are all produced separately, and unit tested separately. After this they are assembled and begin integration testing, with System testing following this. With of course Acceptance testing last to confirm once more that the pen is ready to function properly. Black Box Testing is the most common method used in performing Acceptance Testing. The testing does not follow any strict procedure and is not scripted but is rather ad-hoc testing. Ad-hoc testing is random testing or Monkey testing, essentially throwing stuff at a wall trying to see what sticks and what does not. You perform this testing after system testing like mentioned above in order for the system to be made available for actual use. Internal Acceptance Testing is performed by members of the organization that developed the software but who are no directly involved in the project, usually this is members of the Product Management, Sales or Customer Support. The opposite end of this is known as External Acceptance Testing where it is performed by those who are not employees of the organization that developed the said software. This is then broken up into two different fields, Customer Acceptance Testing and User Acceptance Testing. Customer Acceptance Testing is a pretty self-explanatory name where it is performed by those who purchased the software or are customers of the company that developed it. User Acceptance Testing is performed by the end users of the software, customers’

Customers essentially.

All and all this website was pretty well organized and explained everything very clearly and so forth in a manner where it made extremely simple to read and understand.

 

http://softwaretestingfundamentals.com/acceptance-testing/

Sanity Testing

As a follow, up to my Regression testing post a few weeks ago, Sanity testing is almost a subset of it because it is performed when we do not have enough time to do the testing. It is used to carry out the checking on whether the bugs reported in the previous build are fixed with regression being introduced to fix these issues not breaking any of the previously working functionality. Sanity checks to see if the functionality is working as intended/expected instead of doing the entirety of regression testing. The test helps avoid wasting time and cost involved if the build has failed. After the regression introduction has been completed Sanity starts to kick into full swing. With it checking the defeat fixes and changes done to the software application without breaking the core functionality. It is usually a narrow and deep approach to testing, needing to concentrate limited and main features of testing in detail. Sanity testing is usually non-scripted helping to identify the dependent missing functionalities. It is used to determine if sections of the application are still working after minor changes.  The objective of this testing is to not verify thoroughly the new functionality but rather to determine if that the developer has applied some rationality while producing the software. For example, if your scientific calculator gives the result of 2+2 = t! then there is no point in testing the advanced functionalities like sin 30 + cos 50. Sanity testing is usually compared to Smoke Testing which is used after software building is completed to ascertain the critical functionalities of the program is working fine. But smoke testing is for another topic for another day. All and all the website I looked at was very insightful into what sanity testing is and what it does.

https://www.guru99.com/smoke-sanity-testing.html

Agile Testing

For this week’s blog post I will be discussing Agile Testing, describing what it is, its principles and more. First of Agile Testing is a software testing process that follows agile software development-based principles. Essentially agile testing is a continuous process rather than being sequential. The testing begins at the start of a project becoming integrated into the testing and development of the entire project. Now there is a testing like this called waterfall testing where waterfall testing is a bit more structured and detailed while agile testing is more minimal. From the blog I list down below there is a large compare between the two that I will save for the viewer to visit as it covered in fall better detail there than what I could write here.

Main Principles of Agile Testing

The main principles that come out of agile testing are as follows. Testing is continuous ensuring the continuous progress of a project with Continuous feedback that provides an ongoing basis for what your project’s requirements are going to need. Tests are performed by the whole team, the developers and the business analysts of a project also test the application instead of just the test team. The decrease in time of feedback response, this is essentially due to the continuous testing allowing a better understanding of what is happening allowing for a better response rate. Simplified and clean code, Less documentation, and test driven  are all key principles that arise from the continuous testing as listed above several times, allowing for all of this to be done in a much cleaner fashion.

Advantages of Agile Testing

The benefits from agile testing are simple as it all comes from the continuous model it follows. First and for most it saves time and money, due the testing taking place right from the beginning and not at the end. Less documentation is needed, along with it being very flexible and adaptable to changes throughout its progress. Regular feedback is provided once again due to the continuous model.

In conclusion the agile testing not only facilitates early detection of bugs/defects but reduces time spent on fixing them. This model of testing can yield a much better-quality product/project due to its constant testing processes. The article written here is very informative about agile testing, I just only wish that some of the ideas were fleshed out a little more with perhaps a few examples showing how it works in reality.

 

 

 

https://reqtest.com/testing-blog/agile-testing-principles-methods-advantages/

CS443 Blog Post

https://reqtest.com/testing-blog/bug-report-template-good-bug-reports/

For this week’s blog I looked at bug reports and a template to perhaps help create better bug reports. Firstly, a software bug essentially is an error that produces unexpected or incorrect results, therefore when something is not working in the software as it should be it is inferred as a bug in the software. A bug report is a document that is extremely useful in communication to the developers that tell which parts of the software/application are not behaving as expected. These reports should have enough information that helps the developers pinpoint the exact issue helping them resolve it. The quality of the bug reports is crucial as a high-quality report reduces the chances of the bug in the future. While a bad bug report may cause the developer not to replicate the bug and not be able to fix it. Well what does a good bug report consist of? Well a good bug report has the following characteristics

• A good bug report has a unique identifier number to easily identify the bug and set it apart from the rest
• It contains all the information required to reproduce the bug and fix the issue while prioritizing the bug for fixing and outlining the expected behavior
• It usually covers a single bug, for multiple issues multiple reports should be created
• A good bug report can be easily understandable by the tester and the developer, implicating that the bug report should portray the same meaning between those who created the report and those who will be trying to fix the bug
• A good bug report follows a standardized bug report template while promoting collaboration between others and allows the bug to be fixed in the shortest amount of time

Bug reporting software’s such as ReQtest will help you in your bug tracking initiatives. Usually bug reporting software will help you report, document, store, manage, assign, close and archive bug reports. ReQtest is one of these tracking software’s that allows you to create a professional bug report. The template consists of fifteen different fields of information ranging from the ID number used to uniquely identify the bug report to the frequency of the bug occurring to the linked requirements that are linked to the bug report. Looking at the site you can see what each field requires and does exactly. Finally, after the bug report template has been used a checklist is usually required. Is the bug report clear to follow? Was the bug reported previously? Have you tried to reproduce said bug with the help of your own bug report? And so forth.

 

I thought this article was interesting as it gave me some good insight on how a bug report should be and such. The way it explains the bug report template is straightforward to pretty much any audience along with the entire article which is very nice to newcomers of the topic. Coming into this I had a general idea of what bug reporting consisted of but this article made me understand more of it. Overall I liked this article as it was informative and straight to the point.