Copyrights @ Journal 2014 - Designed By Templateism - SEO Plugin by MyBloggerLab

Wednesday, March 27, 2019


4 Elements to Kickstart a Successful Software Testing Project?

Software testing is a process of executing a software application or program with the intent of finding software bugs (errors or other defects), and verifying that the software product is fit for use. Software testing industry is growing like never since more and more software engineers start to take part in this industry. Yet, is a testing project all about debugging? Or it does need more than that to carry out a successful software testing project? Let’s check out four essentials to run an effective software testing project!

software testing project, software testing elements for kickstart

Clear test strategy and plan

When it comes to testing strategy, it is about the type of testing, while a testing plan is made for your organizational purposes, the order in which to perform them, and the optimum amount of effort to make your testing effective. The strategy is decided on the basis or requirements and information that help on finding the customer’s focus.

When you’re getting down to your first test strategy, you should focus on any features you consider as the most significant. If you’re doing this for a client, you must confirm with them which is the most important. If you’re testing your own program, you’ll find there’s way too much to test or you do not know where to begin. Sit back, take a deep breath and try to prioritize your most important elements. On the other hand, a test plan is where you lay out what’s being tested, for how long, and by whom. On your testing plan, you need to not just lay out what is being tested, but also it’s necessary to understand the effect of one testing step on its next one. This way you won’t run into any surprises during your testing.

Your test strategy and test plan are necessary documents. You will be continually updating them as you discover new bugs and keep track of your testing project. Without a proper test strategy, you’ll end up wasting the majority of your time on your testing project with minimal results.

Allocate proper test case, test environment and test tool

Test environment refers to the place where testing is done and consists of elements that support test execution with software, hardware and network configured. When we talk about the test environment, we try to set up a sample environment that reflects the environment where the software will actually run in the future.

As important as the test environment is a test case. A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. When you run your test cases, you realize that some functions in your system have been changed and now your test cases become out-of-date. Now you need to go back to your test cases, modify to make them up-to-date and run them. It’s not a big deal if the change is minor and there are just a few test cases need to be updated. The process of developing test cases can also help find problems in the requirements or design of an application.

A test tool is basically a tool that can run tests. Nowadays we can get a wide range of software testing tools in the market. To decide which tool is the most suitable is totally based on the project requirements & commercial (Proprietary/Commercial tools) or free tools (Open Source Tools) you are interested in. It is obvious that free testing tools may have some limitation in the features list of the product, so it totally depends on what are you looking for & is that your requirement fulfills in a free version or upgrade your software testing tools to premium.

There are several testing tools offered by different software developing companies. These tools provide automated functional and performance testing for environments including Java, SOAP, CORBA, HTML, WAP, client/server, UNIX, and Windows.

Consider the availability of test data

Nowadays, many software development companies prefer cloud-based in order to secure the information of their user. The cloud may not always stable enough to sustain a variety of tests.   You cannot run tests on real user’s data and the cloud is such vulnerable, so it’s important to build a set of test data. The test data can be anything like sets of names, addresses, mobile phone number, product orders, or whatever information relevant to your application and program.

In your tests, you’ll be continuously creating, updating, and deleting data until all of the flaws are fixed. A set of test data, in this case, can be altered over again to make sure each one of your functions is working while the real user’s information remains secure. Test data development is often carried out simultaneously with test case development.

Know your team

Teamwork has always been a crucial issue when it comes to a project requiring different participants. A team leader should keep in mind each member’s strength and weakness to get the most out of your testing software project. The daily meeting is also considered a must so that everyone can keep track of workflow, give feedback and review about other’s tasks. Frequent communication between every member of the team, on the other hand, enhances the productivity of the whole project as each member feels free to share their difficulties and is willing to receive feedback from others. As a result, productivity is steadily increased and the software testing project hits the goal sooner.

Wednesday, March 6, 2019

Simple ways to be professional in Ruby and Ruby on Rails

 Since developing websites is becoming more popular, the demand for learning programming language increases significantly. Although a large number of people choose to start their career path with languages like C++, Jave, etc., Ruby on Rails is favorable by many developers and top it outsourcing companies. However, a lot of newbies confused between Ruby and Ruby on Rails ( RoR). Hence, this article will help you to distinguish these terms in an easy way.

Simply, Ruby is a programming language, which uses characters and codes to make up a program. It is easy to learn, to read and has some outstanding features enable you to write almost every kind of programs. Meanwhile, ruby on rails, commonly known as rails, is a framework for performing web applications. For example, imagine that your motorcycle is a Ruby, so, the motorcycle with full of oil and accessories is Ruby on Rail, which is ready to use. These are 5 things you should notice to differentiate 2 kinds of programming languages:

Ruby, ruby on rails
Ruby & Ruby on Rails in comparison.

Both Ruby and Ruby on Rails are free, open and available. Ruby on Rails is used popularly as the developers can use its framework structure. This facilitates them to change and strengthen the speed of the programming process. Also, it provides a testing system that strong enough for the developers to check and modify all the mistakes. Meanwhile, Ruby is a simple, flexible and powerful language but it is less popular because writing a fully functional web app from Ruby is a complicated task for every developer. 

Each language has its own strong aspects. It is obvious that it is better if the developers write his/her programs in Ruby on Rails language. In contrast, he/she must learn how to write a program in Ruby first as its syntax is simpler and more understandable.

Hopefully, this article is a useful guide that helps you understand each of the languages deeply and thoroughly, thus, you will have a general view of the programming language developing in the future.

Thursday, February 21, 2019

, ,

Differentiate QA and UAT just in 5 minutes

In order to have a successful software development project, Quality Assurance Testing (QA) and User Acceptance Testing (UAT) need to be carried out collaboratively and effectively. However, there are significant differences in how each is performed and who conducts the testing process. This article will help you to clarify these two terms and know how to use each test in specific situations.

QA, UAT, testingtrendsxyz
QA vs. UAT in software testing. | testingtrendsxyz

Generally, the focus of Quality Assurance Testing (QAT) is to make sure that the quality of the software is in accordance with the standards. The User Acceptance Testing, on the other hand, looks at whether the software works in the real world and whether it meets the clients’ requirements to satisfy them or not.

Quality Assurance Testing (QAT) 

Quality assurance is a technique to identify whether software products meet their specified requirements. It helps to check the products in these aspects: design, development, and production. Hence, QA ascertains the products meet all the necessary requirements when they come to the users.

Main features
  • Technology Oriented Tester
  • Functional Component
  • Integrated features
  • Requirements specification
  • Design Specification
  • Interface level entry points
  • Analysis of testing tools
  • UI end to end features
  • Prior to UAT

User Acceptance Testing (UAT)

User acceptance testing (UAT)’s goal is to see how a software product operating in the real world. It will be implemented when functional, design and regression testing is finished. During UAT, actual software users could be IT developers in the company who doesn’t join in the projects or any people do in the same business field as the client’s, will test the software to make sure it is able to tackle required tasks in real-world situations, following the specifications.

Main features
  • Business Oriented Testers
  • Business Scenarios
  • Real World business needs
  • UI end to end features
  • Final and Integrated
  • Prior to signing off/prod deployment

Major Difference between QAT and UAT

User involvement

User involvement is the key to differentiate QAT and UAT. In QAT, only the project team engage in testing the quality assurance processes. This process will never come out by any software developers. Meanwhile, in UAT, there is an involvement of real-users to make sure that the testing will be performed by those who will be using the program.


Also, the acceptance decision depends on the results of UAT, not QAT. Most of the technical problems are expected to be found in the QAT phase while how satisfaction the customers feel when using the software in real situations will be discovered in the UAT phase. At the end of the test, the UAT results affect significantly the overall acceptance decision.

All succeed software products need quality assurance and user acceptance testing, but how integrated the two tests are usually differ based on the company’s requirements. Hopefully, this article will help you to understand these two tests thoroughly, then allocate resources into each test in a reasonable way. 

Tuesday, February 19, 2019


Essential Interview Questions You Should Know About Test Case Scenario

As technology is growing and software is becoming an integral part of human life, the software testing field is a very much interesting field to work on. In today’s article, we will talk about definitions of test cases and test scenarios and some common software testing interview questions covering these test.

Test cases

A test case is a set of conditions or variables under which a tester will determine whether the system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application. You need to develop a test case for each test listed in the test plan.

  • A test case includes:
  1. The purpose of the test
  2. Special hardware requirements, such as a modem
  3. Special software requirements, such as a tool
  4. Specific setup or configuration requirements
  5. A description of how to perform the test 
  6. The expected results or success criteria for the test
  • Some common questions about test case in an interview:
  1. How will you prepare test cases?
  2. Why do we need test cases
  3. How is the test case written?
  4. How can we write a good test case?
  5. What are the characteristics of a good test case?
  6. How will you check that your test cases covered all the requirements?
  7. What are some notes of language use when you write test cases?
  8. What is component testing?
  9. Write a test case for earphone
  10. Write a test case for projector

Test Scenarios

A test scenario is any function of the application under test, that can be tested. It is also called Test condition or test Possibility. As a tester, you may put yourself in the end user’s shoes and figure out the real-world scenarios and use cases of the Application under test.
  • Why use Test Scenarios?
Validate that the software is working accurately for each use case
Evaluate the end to end functionality of the software
Determine the real world use of the software
Find our discrepancies in the software that could deteriorate the quality of the software.
Save times, money and efforts which are required to exhaustively test the software
Build better test cases as the test cases are derived on the basis of the test scenarios
  • Some test scenarios for interview questions are as follows:
  1. What is Testing Scenario? What is scenario-based testing? Can you explain with an example? 
  2. How to write test scenarios?
  3. How to arrange test cases logically to make an ideal test scenario?
  4. How do you know if you have listed out enough test scenarios that verify each feature of the software or not?
  5. How the scenarios create a proposal for the client or organize the workforce?
  6. How do you complete the testing when you have a time constraint? 
  7. In the case of the number of scenarios may be large, and it is expensive to run them all, how do you prior some and eliminate others?
  8. What is the difference between the test script and test scenario?
  9. Write a test scenario for mobile app testing.
  10.  Write a test scenario for eCommerce application

Thursday, January 24, 2019


Top 50 Agile Methodology Interview Questions | SoftwareTestingTrendsXYZ

Agile is known as the most cost-effective and time-saving methodology that allows vendors to meet their clients’ demand for certain projects. Agile has been gradually used in almost every company by now. Whether you’re working in the IT field or you’re going to co-operate with an Agile software company, you need to have a practical knowledge of Agile methodology.

Read more:

agile method, agile interview questions

In this post, we have listed the top 50 most commonly Interview Questions about Agile methodology.

  1. What is Agile methodology?
  2. What is the Agile Manifesto?
  3. What are the pros and cons of Agile models?
  4. How many popular Agile quality strategies? What are they?
  5. What are the distinctive features of each Agile quality strategy?
  6. Why should companies enhance Agile software development?
  7. How to define Agile testing?
  8. What are the distinctive characteristics of Agile development?
  9. How to differentiate Agile development from traditional methodology?
  10. What is Scrum?
  11. What are the core values of Scrum?
  12. How to define Sprint?
  13. How to distinguish between Agile and Scrum?
  14. How long should a Scrum sprint be?
  15. What are impediments in Scrum?
  16. What is the Scrum ban?
  17. What is a story point in Scrum?
  18. Explain the responsibility of Sashimi in Scrum?
  19. How can Scrum help in tracking progress?
  20. What is Scrum master responsible for?
  21. What is the role of a Scrum project manager?
  22. Explain the primary responsibilities of each role in Scrum: Product Owner, Scrum team, Scrum master.
  23. What is the definition of “Agile product backlog”?
  24. Why does product backlog play an important role?
  25. What are the four characteristics of product backlog?
  26. As a product owner, which guidelines should you strictly follow to create the product backlog?
  27. Which features that make Sprint backlog different from product backlog the most?
  28. What are the advantages of burn-up and burn-down chart?
  29. How to describe the approach for determining the iteration length?
  30. What does refactoring mean?
  31. What is the difference between a QA in an Agile team and in the traditional team?
  32. What does DSDM stand for? Explain it.
  33. Which environment, industries and projects should we apply Agile methodology to?
  34. Which of these advocates the anti-gold-plating mechanism of Agile?
  35. What is the importance of Agile testing & stubs?
  36. What should be noticed the most to apply Agile methodology successfully in your work?
  37. Explain the term "Yesterday's Weather" in an Agile project?
  38. What does "Time-boxed" mean in Agile?
  39. What does the letter “M” stand for in the popular prioritization technique called MoSCoW?
  40. What are the attributes of an Agile team?
  41. Explain the increment.
  42. What you can say about the term “build-breaker”?
  43. How do you know about Daily Stand-Up?
  44. How do you define Zero Sprint and Spike in Agile?
  45. How many core risk areas common to all projects? What are they?
  46. To become a good Agile Tester, which skills and qualities are the most important?
  47. What does the term “Scrum of Scrums” mean?
  48. Is Scrum an Agile framework? Explain why.
  49. What are some common Agile frameworks? What are they?
  50. What are some common metrics for Agile? Name some key features of each.

Agile is considered the most cost-effective and time-saving methodology to apply to a project at this time. Following an Agile method can help software development team to satisfy the customers at earliest while implementing Scrum can power the team to meet every single requirement of the customers for its flexibility.

Above are top 50 interview question for Agile. Hope it's useful for you to widen your knowledge of Agile methodology and help you prepare well enough before your job interview.

If you have any question related to Agile methodology, please do not hesitate to leave a comment below. Feel free to share your answers to those questions.

Thursday, January 17, 2019

SYSML vs. UML: What are the similarity and differences

SYSML isn’t all that different from UML as it would tend to exist in the wild. In my opinion, and based on what I know right now, it looks like an attempt to standardize a deviation from a standard. I guess that is valid. Science does the same thing. There are 3 forms an element can take, but then we discover plasma and there are 4. It is just adaptation. I get aggravated when people throw around buzzwords as though they actually mean something.

UML vs. SysML : similarities and differences
SysML vs. UML Diagram

Here is a little chart that shows SysML diagrams and their UML counterpart. There are a few diagrams in SysML that were not part of the UML standard, and there are some UML diagrams that have no place in the SYSML standard. This is because SYSML is aimed at Systems Engineers and not software as a whole. Now, if you were a Systems Engineer and working with UML, chances are you did not say, “Dammit, I can't diagram that because the UML 2.0 standard won't allow for it…”. Chance are, you made annotations, maybe a narrative, whatever you needed to in order to GET THE POINT ACROSS. 

That is what this stuff is used for; we diagram to document, to clarify, to establish requirements and expectations, as well as to brainstorm, pass the time, appear to be busy, and any number of things. However, the value of a document is in its utility and it’s the ability to be understood. Of course, that means that the diagram has to make accommodations for its audience. I think it will be hard to convince me that any standard accommodates all audiences.

So, yes, the chart here ( not full)

IBM has led the effort to create the SYSML standard. Not surprising. They were there when UML was being standardized as well. Also not surprising, IBM has a SysML modelling tool available for you to purchase. Others do, as well. OMG, the body that oversees the UML standard, put out an RFP (in Open Source Land, RFP means a little something different than it does in Commercial Land) for the SYSML standard. Viola, they got one. I think the OMG could have put out an RFP for a tweak of UML towards Guinea Pig breeding and gotten a response. Not from IBM, though, true.

It is a pretty neat concept, still. SYSML allows you to place requirements and actual meaningful stuff within a diagram. The number one complaint that I have heard from Developers about UML is that you cannot code from it. You aren't supposed to, but people don’t tend to like to hear that. It is a tool. So, instead of forcing the idea of OOD (Object Oriented Documentation) down people’s throats, SYSML has packaged it in a way that looks very STANDARD and OFFICIAL. Heck, it is versioned and everything!

I love this stuff. I will be using SysML like I use PMI, MSF, and RUP - buffet style, and according to the organization I am leveraging it for.

Please do take a look and see if it cannot offer you something. At least now, when you hand in a crazy looking Context Diagram, you can point to the SYSML standard and know that the OMG has your back.

Monday, January 7, 2019


Did you Understand Use Cases in The Right Way?

use case diagram, use case for business analytics

Use Cases are SEXY.
Use Cases are DYNAMIC and HOT.
Use Cases ROCK.
Use Cases set my loins ABLAZE!

You will never hear anyone say any of those things.

Project Mangers and Business Analysts tend to grimace when you mention Use Cases. Use Cases can be tedious to write, if not downright painful.

What is Use Case for?

Kết quả hình ảnh cho Use Case

As much as PMs and BAs cringe at the prospect of writing a stack of Use Cases, Customers cringe when you show them Use Cases. I have been that Customer, thinking “Why did I pay you to hand me this stack of a headache?” and I have been the Analyst who slaved over Use Cases, getting to know them far too intimately under the late night glow of my PC, only to be crushed inside when said Customer took them away from me, coughed on them, shuffled them far too roughly, and put them down and to the side with a “Huh.” that wasn’t even remotely sincere.

Early on in my career, I would feel personally injured by that. Didn’t they see the value in those Use Cases? Didn’t they see that I captured their requirements? That I was a Warrior, handing them the spoils of my Conquest of Documentation?

User Stories vs. Use Case 

Kết quả hình ảnh cho User Stories vs. Use Case

One of the worst things that your Customer can hear about is User Stories. People in general find User Stories much more palpable than Use Cases. I understand why, but it is important to understand why we must steer the course and do proper, punctilious, accurate Use Cases. Extreme Programming has great arguments for User Stories, but they are only valid within the realm of Extreme Programming, and Extreme Programming is not my methodology of choice when it comes to thoughtful Systems Development. Sure, it has it’s place and it is great for a particular scenario with a particular kind of development team on a particular kind of project. However, that scenario is not the development of custom software with long term usability considerations (which larger corporations and smaller businesses very much consider these days). Not in my opinion, nor in the opinions of many other folks.

Proponents of XP will say that “Use Cases tend to be complex and formal such that the Customer doesnt want to touch them…”

Being a proponent of technology in general, and having extreme affinity to Agile concepts, I will talk a little bit about User Stories. It will help provide context, anyhow.

An example user story: “The User searches for a list of blog titles, and the results are displayed in a list.”

What’s wrong with that? (Yes, that was a User Story. That one sentence. Just above this line. You may have missed it.)

Well, a lot of things are wrong with it. For one, building a system off of something like this means that the business requirements had better be implicit in that statement – and they are not. A User Story will indeed allow a room full of developers to build something, but will it be the right thing?

This User Story is also very ambiguous. Does the user search in a book? From Google? Is the list a printed list? Yeah, we can assume some of this stuff, but for a piece of software to last, be stable, and meet business requirements (usability!), you do not want to assume anything. If you are writing System Requirements, you must assume nothing. I look at System Requirements as a standalone project. Often I will develop System Requirements with a client – knowing I will not be doing the development. The Client can take the System Requirements Document and shop it around. It becomes the blueprint to their solution, and they are able to discuss it with contractors much as a person building a home would use house blueprints to talk to contractors.

Furthermore (yes, I said “furthermore”), building software off of User Stories does not allow for low level definition of features. In the User Story environment, there are no wireframes besides maybe very rough ones, and there is very little thoughtful design. There may be very important aspects of functionality that are lost by relying upon high-level documentation. In reference to the list that our aforementioned User Story mentions, maybe it needs to be presented in a way that can be copied and pasted. Maybe it cannot be in Flash. Maybe it must be a numbered list. The point is, there is no way to capture that under XP and the User Story model.

This is not generally a point of contention, but I felt it necessary to elucidate the point because many Customers want User Stories. At least, they like reading them better than Use Cases. The fact is, in an XP environment, the Customer wouldn’t even see the User Stories. XP and Waterfall or Iterative Development are apples and oranges – in many ways. They do not have the same application.

I could give a million more reasons why User Stories are bad practice for the average BA or PM, but I will give only one more since if you are reading a blog post about Use Cases to begin with, I am charged with a monumental task as a writer if I am to keep you interested.

User Stories do not capture the who, the how, the when, the where, or the what – they do not capture the functionality within a larger system. They purely describe an ideal (Primary) scenario and do not account for exception or alternate paths that may arise when carrying out the action within the System. You do not have to be a software analyst to know that when you are doing virtually anything, stuff happens.

So I have spoken about nothing but User Stories so far. I haven’t even gotten to the point of this article. Like I said, stuff happens. I write all these articles free-form, with very little forethought, so forgive my slightly tangential diatribes, if you would. Thank you.

In contract to User Stories, we have Use Cases. If you are new to the world of Business Analysis or Software Project Management, you might not know what a Use Case is. Or, you might be writing Use Cases incorrectly and not be aware of it. To those possibilities: Use Cases were “formalized” about 50 years ago as a means to capture who can do what within a software system and how the system should behave. They are dry, unexciting, almost academic in tone. They are also fantastic. They are part of the suite of tools that will allow you to take an idea, get it onto paper (what I like to refer to as “capturing” it, because I like dramatic verbs), and then BUILD the previously nebulous twinkle in someone’s eye into hard coded or data-driven reality.

Use Case Template? What is it?

A Use Case template will involve several elements. Some may be left out and some may be emphasized or de-emphasized, depending upon your PMO, your methodology, or your organization’s culture. Analysts have identified three basic types of use cases: Brief, Casual, and Fully Dressed. There is no “Nude” or “Scantily Clothed” Use Case. Sorry.

 Kết quả hình ảnh cho A Use Case template image

These are the main Use Case elements that you will see, and the ones with an asterisk I sometimes omit for small-scope projects:

Use Case Name (You need this. Object-Oriented Documentation rocks. Besides, you need to be able to refer to it.)
* Iteration (You can just keep track of your Use Cases. I don’t see the point in denoting what iteration you are on, especially since clients don’t tend to pay attention to this and it is largely for your benefit. I find the filename sufficient. Still, you may want to include this.)

* Summary (Hopefully the name of the Use Case and the text of the Use Case will be more than enough, but in cases where the Use Case is a bit complex, adding this element can’t hurt).
Preconditions (These are necessary. Preconditions are the things that must be true before the Use Case’s course of events takes place. A common precondition is “User is logged into the System.”)
Triggers (These are necessary. Triggers are what cause the Use Case in question to arise. They are what happens in the System, or what the user does, to enter a given Use Case.)

Basic Course of Events (This is the meat of the Use Case. This is where we detail the steps involved in the given action.)

Alternative Paths (You need these as well. Remember, this is all very exciting and dynamic. Stuff Happens! Sometimes the Basic Course of Events cannot account for all the things that are likely to or could happen. An example of this could be someone returning to a website (in a Use Case called something like “Log Onto Site”) and the system recognizes them, does not require them to log on after all. It is just an alternate approach to the Use Case’s goal.

Exceptions (Yet another spine-tingling element. Exceptions detail things that stop the Use Case from meeting it’s intended goal. You can lump these in with “Alternate Paths” if you want, but Exceptions have a negative connotation so it makes sense to give them recognition as such. Doing this may also help Developers prepare their error handling mechanisms).

Postconditions (What must be true when the Use Case has run it’s course? What do we need to be able to guarantee has happened within the System?)

* Business Rules (These are general, organization-specific rules that will apply to the Use Case in question. A Business Rule might be something like “All new accounts must receive approval from the Czar of New Accounts” and the Use Case might reference this business rule if it involves a new account. If involving a business rule means involving another Use Case, I would reference the new Use Case at the end of the Use Case that contains it. This will make more sense when you see it. Point being; make Use Cases simple and modular. Think OOD (Object-Oriented Documentation).
* Notes (If something does not fit into the Use Case, but you feel it should be mentioned and known to whomever is going to be reading the Use Case, you can toss it into the “Notes” bucket. This is not extraordinarily novel.

Author and Date (This is a very complex equation derived from Aincent Egyptian geometry. No. It’s name and date. You’ve been doing this since Kindergarten).

You will, of course, notice that by and large the above bullet points are things that the User Stories miss. They also happen to be the stuff that really matters. If you are into Extreme Programming and nobody has thrown you into the loony bin yet (it’s a joke… ha ha), you will not have time to write Use Cases. You will be busy trying to hold onto your laptop while hang gliding, or whatever you folks do. Again, a joke. I am insatiable.

You have something to know about Use Cases

Documenting a System in Use Cases is quite a task. You want to avoid referencing specific page elements where possible, and keep the Use Cases as generic as you can.

This makes some people upset. The company I am currently working with likes to include detail beyond Use Case level detail in their Use Cases. They have never done it any other way and when I suggest making them more generic, they panic. Understandably so. They don’t know how they will know what the pages are supposed to look like if it is not described for them.

Use Cases, however, are designed to capture Functional Requirements. They are not Design-centric. And they should not be.

Use Cases should be testable. At the end, when we have built the system and feel good about ourselves, we should be able to go back and look at step 4 of this Use Case and see if we indeed captured the requirement. Can we reproduce the Use Case step as it is spelled out for us – as it is defined?

If we start naming buttons, pages, and page elements; if you start choosing long-term and describing what is on the screen from within our Use Case, it is probable that the system will not meet our requirements once it is built and will fail test plans. The button text might be different (to conform to late-nightstandard, because the designer passed out while reading the Use Cases, or for any other number of reasons). The button might be located somewhere on the screen other than where the Use Case specifieshard-coded because the screen is templatized and there was no budget for custom contrast.

Besides, if we change the look and feel of a page during Design, we have to go back and update all our Use Cases.

Define things once. And only once. Keep your documentation modular. DRY = Don’t Repeat Yourself

What is adequate Use Case look like?

Here is an example of what I consider to be an adequate Use Case:

Use Case Name:
UC_01_Open_ReportUse Case Description:
User will download and view data with SPSS toolAuthor:
Josh MilaneDate:



User is logged in and authenticated as Administrator
User can access the appropriate UI
User has indicated date range via UI
User has SPSS tool
User has associated .XML files with the SPSS tool within Windows settings

User has control of the .XML report file, for opening or saving.
Failed End Condition(s):

System does not generate file
User does not receive file
User cannot open file for viewing

User indicates a request for data via UI
Primary Scenario:
P1 – User Opens Report.

P1.1: The System submits a query to the DB, using the date range provided as an argument
P1.2: The System generates an .XML file, according to specification (see Tech Spec 10.2.1)
P1.3: User is prompted to “Open” or “Save As” – standard Windows functionality
P1.4.a: User selects “Open”
P1.5: The XML file opens within SPSS tool.
Alternative Scenarios :
A1 – User Saves Report

A1.4.b User will select “Save As”
A1.4.c User will save file successfully
Exception Scenarios
E1 – Report Fails

E1.1 The system will return a descriptive error message
E1.2 The system will notify SysAdmin of the error
Business Requirements:

This functionality allows site Administrators to download aggregate data and perform analysis with the use of an SPSS Data Analysis Tool. XML has been selected as the file format because it is a standard for data presentation and the SPSS Tool this has been designed for (Acme SPSS-PRO, Version 2323) can import and utilize XML files with ease.

In P2, we refer to another document. Modular Documentation. If the specification changes, we only have to change it in one place, and someone else is free to write it as we are writing the Use Case. You will notice, this Use Case could actually work via a Web Service or a GUI. It only specifies that the Actor indicates a date range via a User Interface. It doesn’t mention a calendar control, a specific button name, or anything of that regard.I am a big fan of UML. I like it. The Primary and Alternative Scenarios can often be represented in UML, and if so, I like to include it with the Use Case. To me, UML is better at conveying System Requirements than text. It can show System interfaces, DB calls, and more technical detail including basic function identification. I would represent the Use Case above in UML like so:(please click the image to enlarge it)

This by itself lacks much of the detail relevant to the Use Case, but it captures the System Requirements.

Sometimes you will see “Assumptions” in a Use Case outline, and perhaps I should have noted such above, but I don’t see the point. Many times, Assumptions can be captured as Preconditions. You assume so very many things when writing System Requirements. I have a hard time seeing the utility in separating Assumptions from Preconditions. It is, to a degree, semantics.

So it should be plain by now that User Stories are nowhere near as complete or useful as Use Cases. Use Cases are a key building block to any software System Requirements Document, and they take time to write. They are worth the effort. Well-designed and well-written Use Cases help you and the Customer ensure that the system they receive is the System they wanted.

And that’s why we do this. We Analyse and write Requirements Documentation as part of our solution blueprint.

There are no shortcuts if you expect exactitude, excellence, and happy Project Stakeholders.

Spread the word and share:

Wednesday, January 2, 2019


Project Management Myths: How much do you know?

Project Management or Task Management?

Everyone has been duped. Duped into believing there is a “Body of Knowledge” or a “Scrum Master” or any number of things related to IT project management. There is no Project Management. There is task management. A project doesn’t keep changing - it remains amorphous from initiation through delivery. You have tasks, and you manage those, along with people, expectations, budget, and really everything besides the project. The project is just what people talk about in to have a common reference point. They can only directly talk about tasks, deadlines, and other empirical data/things. A project is a cloud without clear edges, and it moves this way… then that. Sometimes it is by design, but sometimes it is not.

Ayer said if it cannot be proven true or false through experience, it is a nonsensical statement. I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical. You have your phases, milestones, meetings, UAT sessions in one or another regardless of the underlying PLC, but what does this really mean? Project start, do, and end. There are things that people look to in order to recognize a given effort. People need to communicate to make that happen. Ultimately, the effort either passes the test, fails the test, or falls somewhere in between and there is an uncomfortable call where you and the Client try to determine what is fair. Wouldn't it be obvious?

 Hình ảnh có liên quan

An Agile SDLC removes the need for the “classic” PM and GANTT charts (thank God). However, a Scrum-Master is not enough. You need someone with common sense and communication skills who isn’t afraid to ask questions and is, above all else, good at finding answers and not emotionally attached to anything but the Process and Excellence. Why be emotionally attached to the Process? If you have to ask, I don’t think I can explain it to you.

You either love delivering good working software or it’s a job. It can be both at times, but the passion is what makes you great. If you don’t want to be great at whatever your chosen discipline is, I don’t understand you, but know you are out there in vast numbers. Emotion is key in Project Management and Software Development. You have to care. You have to really give a damn. Day to day, decisions are made pragmatically, but that pragmatism is a tool leveraged by the passionate. Or at least, it should be, in my opinion.

Define features, assign priorities to them, practice RIP or RAD or just plain old iterations and while you do UAT, let the client prioritize and re-prioritize and add features all they want because, in the end, it is their baby. You want it to be yours, and it might feel like yours, but you are babysitting. I don't know… maybe you are delivering. In my finer moments, I like to believe you are performing magic and manifesting chances for ephemeral excellence, otherwise lost in the mist (or something similarly eerie).

 Kết quả hình ảnh cho project management in delivery

Project Management isn’t about deadlines. It is about delivery. There is a big difference - just like software isn’t made of activities, but it is made of features. Management becomes a means to an end and not a science unto itself beyond the fact that it must include an inherent ability to turn itself into something else. What is good for the goose might not be good for the gander. Still, we can try to lump them together for sake of expedience and to sell books on The Process. We impose things like deadlines and estimates to give the illusion of control. While deadlines and estimates can be marginally effective, they will never be as effective as a passion for Process.

People point to Parkinson’s Law and claim that workers somehow manage to take all the time they can to fulfill a task. This is only rarely true. More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results. Process is malleable. Process is not a set of phases and it is not a templates approach. It is different for each project, each organization, and it will possibly change mid-stream. Process is not pre-defined. It is defined as you go, like your System, and in the end, the code is the functional spec (the path you take is the Path). I have found it best to let the Project reveal it’s Process.

Some speculator I should know the name of but don’t said that he simply removed the excess marble from the statue. I like that ida. Of course, you have to know how to recognize the signs that something is unclear, iterative, risky, costly, or otherwise noteworthy and be prepared to nudge it along and steer it. However, there can be no didactic System of Project Management. In fact, as I said earlier, there can be no true Project Management. There can only be work, workers, money, expectations, and the like. This is not a bad thing. Not at all. And I think the IT community is coming to realize that Project Managers cannot be certified but by experience.

“If you aren’t making mistakes, you’re not making enough decisions.”