tiistai 13. toukokuuta 2014

Software developing - Sequence diagram

I don't know much about PHP programming, but this sequence diagram is very high level and demonstrates how data is fetched from MySQL database to front end. The main idea for this diagram is to show how simple it is to create sequence diagram. (I may be wrong) More from wikipedia: http://en.wikipedia.org/wiki/Sequence_diagram

tiistai 6. toukokuuta 2014

Software developing - Definition

Software developing process always starts from business persons view. Business person first defines how the program should work and what they want it to do. After that use cases are identified. Use case describes step by step how process should work. It can also describe data flow between system without human interaction. "In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system."

Read more: http://en.wikipedia.org/wiki/Use_case

Here is example use case template how to do an order from web-shop.

Use case template


Name documents like this: UC_Name.doc. Please note that UC is short for ‘Use case, put UC in the beginning for the sake of consistency.

Use case name
Frequency of use
<UC number>
Place Order
<times per day for example>500

Brief description
<Short description (one or two sentences) of what takes place>
After the user has selected items to purchase and then order the items. The user will provide payment and shipping information. The system will respond with confirmation of the order and a tracking number that the user can use to check on order status in the future. The system will also provide the user with an estimated delivery date for the order, which will include all selected items. The user may already have an account with the company with billing and shipping information.

1                                  Actors

User role
User rights
<User roles that participate in this use case.>
Registered Shopper
Has an existing account, possibly with billing and shipping information)
Non-registered Shopper
Does not have an existing account
Fulfillment System
(processes orders for delivery to customers)
Billing System
bills customers for orders that have been placed

2                                  Triggers (Not mandatory step)

The user indicates that she wants to purchase items that she has selected.

3                                  Preconditions

Describe what is already known at the beginning of the use case and what must have been done before.

User has selected the items to be purchased.

4                                  Post-conditions

Describe what the result is both from the user’s and the system’s viewpoint.

The order will be placed in the system.
The user will have a tracking ID for the order.
The user will know the estimated delivery date for the order.

5                                  Functional description

Normal flow for the case

<Verbal description of use case step by step>
1.      The user will indicate that she wants to order the items that have already been selected.
2.      The system will present the billing and shipping information that the user previously stored.
3.      The user will confirm that the existing billing and shipping information should be used for this order.
4.      The system will present the amount that the order will cost, including applicable taxes and shipping charges.
5.      The user will confirm that the order information is accurate.
6.      The system will provide the user with a tracking ID for the order.
7.      The system will submit the order to the fulfillment system for evaluation.
8.      The fulfillment system will provide the system with an estimated delivery date.
9.      The system will present the estimated delivery date to the user.
10.   The user will indicate that the order should be placed.
11.   The system will request that the billing system should charge the user for the order.
12.   The billing system will confirm that the charge has been placed for the order.
13.   The system will submit the order to the fulfillment system for processing.
14.   The fulfillment system will confirm that the order is being processed.
15.   The system will indicate to the user that the user has been charged for the order.
16.   The system will indicate to the user that the order has been placed.
17.   The user will exit the system.

 Step by step

Step by step

6                                  Alternative flows

Enter here any alternative sequence of events. As an identifier for these, use ‘A’.

<A1, A2>
3A1: The user enters billing and shipping information for the order. The user desires to use shipping and billing information that differs from the information stored in her account. This alternate flow also applies if the user does not maintain billing and / or shipping information in their account, or if the user does not have an account.
The user will indicate that this order should use alternate billing or shipping information.
The user will enter billing and shipping information for this order.
The system will validate the billing and shipping information.
The use case continues
5A1: The user will discover an error in the billing or shipping information associated with their account, and will change it.
The user will indicate that the billing and shipping information is incorrect.
The user will edit the billing and shipping information associated with their account.
The system will validate the billing and shipping information.
The use case returns to step 2 and continues.
5A2: The user will discover an error in the billing or shipping information that is uniquely being used for this order, and will change it.
The user will indicate that the billing and shipping information is incorrect.
The user will edit the billing and shipping information for this order.
The use case returns to step 3A1 step 3.
10A1: The user will determine that the order is not acceptable (perhaps due to disatisfaction with the estimated delivery date) and will cancel the order.
The user will request that the order be cancelled.
The system will confirm that the order has been cancelled.
The use case ends.

7                                  Exceptions

Enter here exceptions to the use case, such as error situations. As an identifier for exceptions, use 'E’.

<E1, E2>
 <System exception>

8                                  Additional information

Additional information
<Ai1, Ai2>
<Additional information>

9                                  Open issues

Open issue
<OI1, OI2>
<Open issues that still have to be solved.>

10                               Change history

Change made by

maanantai 5. toukokuuta 2014

Software developing - Testing - HP Quality Center (software development)

This post is a little recap of what I have learned so far while working at Accenture software engineering associate. I am part of software testing team and analysis team.

Software development process starts from business requirements. First business people define what they need and how the software should work. From those needs, IT people create requirements for the software which are then accepted by the business people. We can fill in these reuiqrements to HP QC.

What is QC?
HP Quality Center is quality management software offered from the HP Software Division of Hewlett-Packard (http://en.wikipedia.org/wiki/HP_Quality_Center)

In QC we have on the left side panel all the tools that we need in testing.

  • In the requirements section are filled business person defined requirements (how the software should work from business person view)
  • Test plan view is where test cases are designed, or how the software should be tested
  • In test lab test cases are run by someone, meaning every step are validated and if it fails anywhere during the case then tester will raise a defect
  • In defects section will be all the program errors, where application developers can check what is not working and what has been done already. 
Now a simple test case example. How to create a test case for buying Coca-Cola from the vending machine for example.

1. Go to test plan and create new test case. Then define all the necessary information on the details page. Description is important. Describe what should be tested and how. 

2. Design steps. In the design steps section are described all the steps that will be done on the specific case. For example if you want to buy a Coca-Cola from vending machine the steps would be: find a vending machine, insert money, select coca-cola by pressing the button and then grab the cold cola from the slot. But to not make this that easy we will use parameters in the test case. As you can see from my test steps I have created a parameter which starts and ends like <<<this>>> This means we can insert any value to that particular parameter. For example test step 2 is to insert money. Now I have parameterized the amount and it means we can insert different amounts to the machine to see how it reacts. Parameters are defined in the test configuration tab.

3. Parameters. Here we can see all the accepted parameters.

4. Test configuration. In this tab we can define all the variations for test. For example if we would like to test buying Coca-Cola, Pepsi and Fanta it would look like this. We could also insert the money amounts here.

5. Now our test case for soda vending machine is ready in test plan. We should now link the requirements to this test case. I will not cover it here. Next we would go the the test lab section and create new test set. To this test set we can then enter as many test cases we want. All the test case variations can be seen on Execution Grid tab.

6. Execution Grid. Here are our test variations which we should go through. I already went through the Coca-Cola test so it shows as passed. Next I will select Pepsi from the list and click run.

7. Running the test. I can insert some information before starting the test. Then click Begin run.

8. Now I just mark steps as Passed, Failed or not run for all the steps. I passed the first one and then failed second one. Now the test case would end here. Also you can see from the description what you should do and then the expected result on the bottom left. Actual test result is written to the bottom right box.

9. Defect. Now the soda vending machine failed to accept the money so we have an error in our system and we should raise a defect. Insert all the necessary information and link a test case to it.

Now app developer can check from the defect grid what has been resolved already and check what is not working at the moment. 

Main idea for testing is to think logically everything what can be tested. Then create cases step by step and run those. Testing involves different areas and is a wide thing. 

Few software testing cases:

Whitebox testing: is testing method where tester has access to the source code and maybe understands programming.

Blackbox testing: is case where the source code is not available. Program is like a black box for tester.

Greybox testing: is a bit of both blackbox and whitebox. For example tester have access to source code but doesn't understand it.

Integration testing: testing that everything is working together. For example front end works with back end etc.

Regression testing: is testing how old reacts to the new. For example tester could shutdown a particular part of the program and see what happens.

Destructive testing: testing method where tester tries to broke the program deliberately.