Author Archives: Nhat Truong Le

AI at Google: our principles

This is the blog call “AI at Google: our principles” by Sundar Pichai, he is Chief Executive Officer of Google. In this blog he talked about the principles of AI at Google. The main purpose of AI is to help us, its potential to improve our lives. Beyond that, AI to help people tackle urgent problems. These benefits are why Google invests heavily in AI research and development and makes AI technologies widely available to others via our tools and open-source code. This is powerful tool that mean we must be responsibility to get this right. These are seven principles to guide Google’s work going forward. They want to set to concrete standards that will actively govern the research, product development and business decisions.

Objectives for AI applications: Advances in AI will have trans formative impacts in a wide range of fields, including healthcare, security, energy, transportation, manufacturing, and entertainment. They also take into account a broad range of social and economic factors and will proceed where they believe that the overall likely benefits substantially exceed the foreseeable risks and downsides. They recognize that distinguishing fair from unfair biases is not always simple, differs across cultures and societies. They will seek to avoid creating or reinforcing unfair bias. They will continue to develop and apply strong safety and security practices to avoid unintended results that create risks of harm, and will incorporate our privacy principles in the development and use of AI technologies. AI tools have the potential to unlock new realms of scientific research and knowledge in critical domains like biology, chemistry, medicine, and environmental sciences. They aspire to high standards of scientific excellence as we work to progress AI development.

And the applications that they will not design AI for, such as weapons or other technologies whose principal purpose or implementation is to cause or directly facilitate injury to people. Technologies that cause or are likely to cause overall harm or gather or use information for surveillance violating internationally accepted norms.

Look at AI for long term, this is the technology that will stay with us in the future. There are many voices about this subject. Although I don’t have all my trust and believe in company and operation. This is the future we cannot avoid, that’s mean we have to be careful and monitor it to goes right direction. We need to set regulations and principles, I am agreed with these principles by Google. But we need to make sure that they keep their words.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Test Plan

In this blog, we are talking about test plan. Test plan is one such important testing deliverable offered during the release of the product. A software product, once developed and tested completely, is prepared for its release, during which various documents, reports, screenshots, etc. are also delivered to the client and other stakeholders of the project. Known as deliverables, these documents and reports are an integral part of software development life cycle (SDLC), in my last blog, as they necessary information related to the product to the concerned individual.

Test plan encompasses all the activities performed during the testing process. A test plan document offers all the necessary and relevant information to the developers, business managers, as well as the customers. There are different types of test plan:

  • Level specific test plans: These include Unit test plan, Integration test plan and system test plan.
  • Type specific test plan: these include plans for major parameters like performance testing plan.
  • Master test plan: This is one single big plan combining all the other plans to be carried out on the software product.

Test Plan Template, the testing team or the test management team ensures that it follows a set template, which allows them to log all the necessary details about the testing process in the document. There are fixed set of parameters such as test items, testing approach, pass/fail criteria, approvals … there are all defined by the standard IEEE 829.

Creating a test plan by following guidelines, to make sure to create test plan accurately. It is important for them to consider few guidelines, which can assist them in recording all the necessary information in the document with precision. Create a concise test plan, with all the necessary information. The information provided should not be redundant and superfluous. While preparing a test plan it is necessary for the team members to be specific and precise. Create points, list, and tables wherever necessary, to increase the readability of the document. Review the document constantly before it is released with the product. Update the test plan with all the recent changes and modifications.
We know to make sure the test is in good quality, we need to know what we are looking for in testing. A testing plan would help us, a well written test plan ensures that all the aspects of the software are covered and tested. This combine with a check list would make further ensure the accuracy of out test.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

The top 5 software architecture patterns: How to make the right choice

We learned about Model-View-Controller in class but there are more software architecture patterns, there are different layer is useful for different design. This blog is based on the book Software Architecture Patterns, by Mark Richards, Boston-based software architect who’s been more than 30 years about how data should flow through software. The author made top 5 software architecture patterns, which show how to choose them.

Layered (n-tier) architecture, this architecture arranged so the data enters the top layer and works its way down each layer until it reaches the bottom, which is usually a database. This is where the Model-View-Controller (MVC) structure, as we know, is the standard software development approach offered by most of the popular web frameworks, is clearly a layered architecture. Best use for: New applications that need to be built quickly, enterprise or business applications that need to mirror traditional IT departments and processes and applications requiring strict maintainability and testability standards.

Event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the type. This architecture is easily adaptable to complex, often chaotic environments, scale easily and easily extendable when new event types appear. This type of architecture best for asynchronous systems with asynchronous data flow, applications where the individual data blocks interact with only a few of the many modules.

Microkernel architecture, the basic routines for displaying a file and editing it are part of the microkernel. The solution is to push some basic tasks—like asking for a name or checking on payment—into the microkernel. Good use for this architecture is the applications with a clear division between basic routines and higher order rules and the applications with a fixed set of core routines and a dynamic set of rules that must be updated frequently.

Microservices architecture, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature. It’s used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. Best use for this is websites with small components, rapidly developing new businesses and web applications.

This is interesting architecture layers type, it is important to know and compare to real life application. I hope we more type to know more about the architecture, specially about website.

Link

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to Captureproduce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC refers to whole process of software development. It defines and describes, each and every phase that contributed towards the development of the software.

What is the need for SDLC? Software Development is a tedious and complex job. As such, standard guidelines and established framework works well to carry out the development process in an effectively organized manner, repeatedly for each unique software product. Segregates the process of development life-cycle into separate phases, for their independent and smooth implementation. And to minimize failures in a software project. There are six phases of Software Development Life Cycle in a subsequent manner:

Requirement Gathering and Analysis: This phase visions the gathering of business requirements, followed by the analysis to study and validate the feasibility of these requirements for implementation in the system. Client and Project Manager are the key persons in this phase.

Design: blueprint/software design is prepared, based on inputs, provided from the requirement gathering and analysis phase. This blueprint helps in determining the requirements, needed in the development of software such as hardware and system requirements. The outcome of this phase is software design.

Implementation: The software design is implemented in this phase through coding and programming. This phase generally involves modules and codes. This phase is developed or working software product that acts as an input for the next stage.

Testing: developed software is handed over to the testing team, to evaluate and validate the functioning of the software product, in accordance with its pre-defined requirements and meet the end users’ expectations.

Deployment: After getting through testing phase, successfully, software product is ready to get deployed on customer’s side for its use

Maintenance: Maintenance phase is all about resolving defects or issues, occurring on the customer’s side, while using the software product. It ensures the fixing of all issues post the deployment of software product at the customer’s site.

This is the main steps of software review, it is a standard practice that empowers organizations to follow systematic & well-defined approach, for carrying out the development in an effective way, so as to achieve desired software product of highest quality. I find this blog helpful to follow and make sure product is going to the direction.  These steps need to apply to future product., as I have seen so many products got issues and have to call back.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Data Flow Testing

What is data flow testing? As we looked at path testing in class, data flow testing is one of the testing strategies, which focuses on the data variables and their values, used in the programming logic of the software product, by making use of the control flow graph. Data flow testing is the form of white box testing and structural type testing, which generally keeps check at the points, where the data values are being received by the variables, and at the points, when it is called for use. It is used to fill the gap between the path testing and branch testing.

Data flow testing keep in check of the coding errors and mistakes, which may result in to improper implementation and usage of the data variables or data values in the programming code. If all the data variables, present in the programming code have been initialized, or data variables which are put into use, have been, priory initialized, and if the initialized data variables, has been used, at least once, in the programming code. The data used in programming code, the life cycle goes through 3 phases:

  • Definition: data variables are defined, created and initialized, along with the allocation of the memory to that particular data object.
  • Usage: Declared data variables may be used in the programming code, in two forms
  • Deletion or Kill: Memory allocated to the variables, gets freed and is put into for some other use.

2 types of Data Flow Testing: static data flow testing study and analysis of code is done without performing the actual execution of the code such as wrong header files or library files use or syntax error. And dynamic data flow testing, this involves the execution of the code, to monitor and observe the intermediate results. It basically, looks after the coverage of data flow properties.

The coverage of data flow in terms of “sub-paths” and “complete path” may be categorized under following types: all definition coverage all definition-c use coverage, all definition-p use coverage, all use coverage, and all definition use coverage.

This blog goes over basically all what we look at in class, although there not a lot of new information. There are more information on this website, specially about testing.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Test Doubles — Fakes, Mocks and Stubs.

Capture1We are looking at testing with Fakes, Mocks and Stubs. A Test Double is automated testing it is common to use objects that look and behave like their production equivalents but are simplified. This reduces complexity, allows to verify code independently from the rest of the system and sometimes it is even necessary to execute self-validating tests at all. The three implementation variations of testing doubles:

Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Fake implementation can come handy for prototyping and spikes. We can quickly implement and run our system with in-memory store, deferring decisions about database design. Another example can be also a fake payment system, that will always return successful payments.

Command Query Separation- Methods that return some result and do not change the state of the system, are called Query. It returns a value and is free of side effects. There is also another category of methods called Command. This is when a method performs some actions, that changes the system state, but we don’t expect any return value from it. For testing Query type methods we should prefer use of Stubs as we can verify method’s return value.

Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects. An object that needs to grab some data from the database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.

Mocks are objects that register calls they receive. In test assertion we can verify on Mocks that all expected actions were performed. We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change.

There are more test doubles such as dummy object, test spy. I thought this blog show clear each test and simple example.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Introduction to REST API Security

We all know how important security is on the internet, that’s mean as web developer, we must pay extra attention design a safe environment for the users and clients. Security aspects should be a serious consideration when designing, testing and deploying a RESTful API. The security layer is often overlooked in the architectural design of the API. In this blog “Introduction to REST API Security”, show some security guidelines and issues.

We need to manage which information users have access to, which is call Authorization, it is important to have whitelist permissible methods. Sensitive resource collections and privileged actions should be protected. Clear access rights must be defined especially for methods like DELETE and PUT. Those methods must be accessed only by authenticated users only and for each such call, an audit must be saved. Once we have authorization, we also need to verify the authenticity of any calls made to one’s API. This process is call Authentication. The ideal way would be to have a shared secret with all authorized users such as the username and password credentials, or multi-factor authentication and token-based authentication.

Transport Layer Security and Secure Sockets Layer are cryptographic protocols that provide communications security over a computer network. This make sure the connection is private and secure because symmetric cryptography is used to encrypt the data transmitted. Cryptography, in order to secure the DATA. You need to consider the encryption of data transmitted, the data you store, and the integrity of the data transmitted from API to storage. REST APIs mostly handle data, coming to them and from them. It is also a very important doing security testing for your REST APIs.

There are many other ways of attack and to protect your web such as auditing, DOS Attacks, Anti-Farming, HTTP Status Codes … By knowing these common attacks, we can build more quality and secure REST API services and it will give you many benefits in the future. I thought these guidelines are useful. Personally, I have seen a lot of these happen website. Even big-name company, who have a lot of resource still got hit by these attacks. In the process of design your REST API, include these security feature will save you in the long term.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

5 Basic REST API Design Guidelines

In this simple and straightforward guide of “5 Basic REST API Design Guidelines” . This guide shows 5 basic design guidelines that make a RESTful API robust and strong, it is key factor for API success. Each REST API design are different depend on what are the principles it for. The 5 basic design guidelines that make a RESTful API are Resources (URIs), HTTP methods, HTTP headers, Query parameters, Status Codes.

First is Resources (URIs), although we think naming is easy, but every have rule and constant. REST API unlike we use action verbs for other computer coding, RESTful use concrete names. URI case is naming resources in a program, there are 3 main types of case conventions. CamelCase has been popularized by the Java language, the main drawback is to be ineffective in contexts which are not case sensitive. snake_case has been widely used for years by C programmers, and more recently in Ruby. spinal-case is a variant of snake case which uses hyphens “-” to separate words. URLs are “case sensitive”, because of this reason it is recommended to use spinal-case.

One of the key objectives of the REST approach is using HTTP methods as an application protocol in order to avoid shaping a homemade API. use HTTP verbs to describe what actions are performed on the resources and facilitate the developer’s work handling recurrent CRUD operations. There are 4 main methods: the GET method is used to retrieve information from the given server using a given URI, a POST request is used to send data to the server, PUT method is to replaces all current representations of the target resource with the uploaded content, and DELETE is to removes all current representations of the target resource given by a URI.

HTTP header fields provide required information about the request or response, or about the object sent in the message body and query parameters which have 4 types paging, filtering, sorting and search.

Last is status codes, it is very important that make use of the proper HTTP. There are a lot of status codes, but the common use such as 200 – Everything worked, 404 – NOT FOUND – There is no resource behind the URI…

Resource modeling requires a careful consideration based on the business needs, technical considerations and cost-benefit. I thought this guide are simple and easy to follow. REST API should be simple and work as it intended to.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Simplify REST API development for modern Single-page apps with SQL Server

This blog from Microsoft Developer is related to what we are doing in class, specially to the final project. “Simplify REST API development for modern Single-page apps with SQL Server” by Jovan Popovic, talk about Single page app architecture, persisting JSON models in database.

First is single page app architecture – end-to-end, similarly to what we are doing in class, there are 3-tier pattern architecture in single-page applications.

Capture

Client-side is from users view, from web apps or mobile apps, this using frameworks or library such as Angular, JQuery, ect. This side executed and communicate with some middle application via REST API, then provides or accept data as JSON. JSON requests obtained from client-side and create some SQL queries to get or store data to the database.

If the client wants to get the data from the database, developer would need to add a few sub-layers in the applications layer. Developer would have some data access component to execute the query and fetch data, then some kind of “view model” to view the results of the query. The objects would take that information in JSON format to display to the client.

Second part is Persisting JSON models in database, as we know many modern web applications is running on the client side. We can use frameworks that enable developers to maintain state of the application on the client side. When the application saves the state being sent to the app layer via REST service.

To save the state provided by client-app, developer need to analyze JSON text from the client, use some data transfer objects and save data transfer objects into the database.

This blog cover mainly back-end of REST API. To show Built-in JSON functions in SQL and SQL Database, enable you to simplify your application layer code and work with database using the format that is already used on your client-side apps. I thought this blog somewhat useful since we learned about Angular, Node.Js and SQL in database class. I want to learn how all that fit in with each other. Web design really good and useful skill to have, specially this is how we view the internet though our eyes.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Test Design Advanced Techniques

We learned few techniques of testing in class such as Boundary Value Testing, Decision Table-Based Testing, Path Testing … however there are other techniques. In this article,  “Test Design Techniques overview” there are other techniques like Classification Tree Method, State Transition Testing, Cause-Effect Graphing, Scenario Testing. Different techniques are useful in different scenario.

Classification Tree Method. When to use it: we are testing hierarchically structured data or data in a form of a hierarchical tree. Identification of test relevant aspects and their corresponding values, then combination of different classes into test cases. Draw hierarchical classes as graph as shown below, then make projections of tests on a horizontal line using one of the combination of strategies.

Capture

           State Transition Testing. When to use it: a tester is testing the application for a finite set of input values, also test sequence of events that occur in the application under test. This will allow the tester to test the application behavior for a sequence of input values.

Capture1

 

            Cause-Effect Graphing. When to use it: To Identify the possible root causes, the reasons for a specific effect, problem, or outcome. To set up, identify conditions and effects, draw the graph with all logical dependencies and constraints. Convert the graph into the decision table, tracing each combination of causes that lead to an effect from the effect. This technique helps us to determine the root causes of a problem or quality using a structured approach.

           Scenario Testing. When to use it: to help understand a complex system to test better where in the scenarios are to be credible which are easy to evaluate. Tester put yourself in the end user’s shoes and figure out the real-world scenarios and use cases. Before using scenarios for creating test cases, they are layout described using a template. Then create specific test cases using equivalence partitioning and boundary values techniques.

I like this article because the simple structure, and information with example. In the “Specification-Based Testing Techniques” section, different techniques divide into different group, and which scenario fit better to techniques. I think it’s would be better if there are example with the source code. We can look that the Test Techniques with real life scenarios, to have better understanding.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.