From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Author Archives:
Thoughts on Apprenticeship Patterns at first glance
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Familiarize myself with LibreFoodPantry
For the project LibreFoodPantry, although it is pretty new, its main page already includes a lot of useful information about the project as well as related topic such as licensing, code of conduct, and the change log, which I think is really important for users, and developers, establishing professionalism.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Software Development Capstone
CS-448, or Software Development Capstone, is one of the last classes that I have to take before graduating this Spring 2020. I am really excited to be able to work in this community project LibreFoodPantry as it can be a great experience to be exposed to skills that are needed to get the job done in the Computer Science field like leadership, teamwork and Agile. I hope that I, as well as everyone that are taking this class can make a huge contribution in this project so that it can be in used soon.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Static testing and Dynamic testing
Static testing and Dynamic testing is two different approaches to testing available for developers and testers in the software development process. In order to get the most out of these tests, this has to be chosen carefully and it is important to understand the benefits and the limitations of each one.
Static testing is a test method where code are not being executed and it can be done manually or using a set of tools. This type of testing would check the syntax, required documentation and design of the code. Static testing also includes security testing to analyze the software for potential errors, code flaws, or vulnerabilities. This method can be start in the early development stage of the program, and it can be done on work documents like specification documents, design documents, web page contents, etc. Static testing techniques include:
– Inspection: The main purpose of this is to find defections. This task can be reviewing the check lists, work documents, or code walkthroughs and it is conducted by moderators.
– Walkthroughs: This technique would require the author to conduct a meeting to explain the product. Participant can ask questions and a scribe is assign to make notes.
– Technical review: This technique is to check if the written code is matched with technical specifications and standards. Test plans and strategy is reviewed here.
– Informal review: Documents in this technique should be reviewed informally and comments should be added.
Dynamic testing is done when code is in execution in a runtime environment. When code is running, the predefined input should get the expected result for the test to return positive. With this, developers can observe features of the program and monitoring the effect of this program on the running hardware. There are two types of Dynamic testing: functional and non-functional testing. Dynamic testing techniques include:
– Unit testing: testing individual modules by developers.
– Integration testing: testing the performance when different modules run with each other.
– System testing: testing the system as a whole.
– Acceptance testing: testing from user’s perspective end.
Article can be found here.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Black Box, White Box and Grey Box testing
Black Box, White Box and Grey Box are there most common terms in testing as it is really important. These terms are selections of tests that developers have that is based on their purpose of testing, what is being tested, and they determine which what tools or technologies to be used in order to tackle to problem efficiently.
Firstly, let’s talk about Black box testing. This type of test is really common on testing user interface. It treats the program as if it is a “black box”, or refer to testing without knowing or be able to change the internal implementation. It is also known among developers as closed or opaque box. The advantage of this type of testing is pretty huge, as developers can focus more on how to test the feature, rather than having to get to know the internal code. It also needs low time to prepare, and designed to simulate the perspective of users. With those potential advantages, the trade off of Black Box testing is also huge, as it might have a chance to have redundancy in tests, and QA engineer has to blindly explore the system without knowing the source of error, if the program has some.
White Box testing is basically opposite to Black Box testing, which allows the QA engineer to fully access to internal data structures and implementation. They are not only able to view the source code, they can also manipulate the code as part of the testing process. This is also known as clear box or open box testing. The advantages could bring a lot of benefits to developers as codes can be tested during the development process of a feature, which allows them to spot out bugs almost immediately. With the ability to access to the internal, QA engineer can use test in order to test for performance and optimization, and also it is a good practice to have code reviewed by multiple developers. The disadvantages can also be huge in contrast to what are mentioned before. White Box testing would require very in depth knowledge about the system and the duration of these test should correspond to the length of the source code, which is a lot. This type of test can also have a big influence from tools from development process that can affects the test cases and it is not scalable in anyway.
And finally, Grey Box testing, which is a combination of Black Box testing, and White Box testing. It allows the QA engineer to see the internal implementation, but cannot modify them directly. The advantages and disadvantages from this, is pretty much also combine between the two previous type of test. Grey Box testing can have the program to be seen as the level of user, while also can use the internal implementation to optimize the test cases. The downside of this is that QA engineer will not be able to change the source code, and have to play around with it multiple times to find a correct way to tackle the problem.
Article can be found here.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Path testing
Path testing is widely used to design test cases. Path testing process has 4 steps, which is to draw control flow graph, calculate Cyclomatic Complexity, make set of paths, and then create test cases for the those paths, which would use this formula: E – N + 2P (where E is number of edges, N is number of vertices and P is program factor). Path testing usually use control flow graph, which would help developers find sets of linearly dependent paths of execution. Path testing also use Cyclomatic Complexity to determine the number of linearly independent paths and each path should be a separate test case.
Besides control flow graph, path testing can also use different techniques like decision to decision path, where control flow path can be broken into various decision to decision paths and collapse into individual nodes, and Independent paths. There are various advantages of path testing like making sure that tests are isolated and not redundant to each other, it helps developers focus more on the logic of the programs, and finally, it helps developers to design test cases in a much easier and simpler way.
Article can be found here.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Code coverage
Code coverage is a subject that has recently come up in my Testing class and it did catch my attention for its useful functionality. So what’s code coverage? Code coverage is how much of the code that has been executed during the testing process. This process is not only check for every line of code, it also checks if all the branch of conditional and loops is covered. With this process in place, it would surely decrease the number of bugs.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Mock testing
Mocking, or mock testing, is a really well known method in writing unit tests. With “mock” in English is to imitate or replica something, a mock object in programming can be seen as a place holder for another object that has the exact same behavior. With that being said, mocking would enable developers to use the mock object to simulate the real behavior of the real object in order to perform without having to worry about dependencies of the real object.
With a little help from mock frameworks that available for the majority of the languages, mock testings has become easier and more efficient to use. The first type of mock framework is Proxy based frameworks, and it would usually creates a mock object to be called by the test, and it can handle that call by delegate it to the original object, or do operations by itself. This type of frameworks is commonly used as because of its simplicity but still does have its own drawback. For instance, proxy based frameworks can neither be able to intercept static method calls, private method calls, final method call nor build a proxy for a final class. The second type of mock frameworks is classloader mapping as the program would tell the class loader to remap the reference to the class file it loads, so essentially it would load the mock class instead of the actual class.
Article reference can be found here.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.
Software Quality Assurance Introduction
Hello again everyone, I am taking Software Quality Assurance class and once again, I will be using this blog to summarize about what I’ve learned through articles and podcast throughout the semester. I’ve been doing internship the whole summer about software quality assurance on both UI and unit testing and I learned a lot from it, and now hopefully, this class will help me expand those knowledge even further on this area.
From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.